Subject: [Tsvwg] ECN nonce snag in TCP ESTATS MIB

From: Matt Mathis <[email-masked]>
Date: Wed, 13 Dec 2006 14:18:05 -0500 (EST)

Folks, this needs TSVWG input....

The document draft-ietf-tsvwg-tcp-mib-extension has been stalled due to a
"DOWNREF",  a normative reference from a standards track document to
to a less mature document.  In this case to an Experimental Protocol, RFC3540,
Robust ECN Signaling with Nonces.    The problem is with one object:

tcpEStatsPathECNNonceRcvd  OBJECT-TYPE
       SYNTAX          ZeroBasedCounter32
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
          "Number of ECN Nonces (NS bits) received."
       REFERENCE
          "RFC3540, Robust Explicit Congestion Notification (ECN)
           Signaling with Nonces"
       ::= { tcpEStatsPathEntry 34 }

The recently posted doc is draft-ietf-tsvwg-tcp-mib-extension-13.txt
The current working draft is at:
http://www.psc.edu/~mathis/TcpExtendedMib/draft-ietf-tsvwg-tcp-mib-extension-13bis.txt
With an html word diff at:
http://www.psc.edu/~mathis/TcpExtendedMib/draft-ietf-tsvwg-tcp-mib-extension-13bis.wdiff.html

There are two obvious approaches to fix this:
1) Pursue the downref procedure in RFC 3967.  This entails writing a
justification for the downward reference and re-issuing the IETF last call.
2) Deleting the object entirely.  Since this is a substantial technical change
to the document, it requires re-issuing the TSVWG LC and possibly the IETF LC.

I am willing to pursue either approach, however I think it would be best to
match the likely ultimate trajectory for RFC 3540.

My questions:
Are there any known implementations of RFC3540 in the field?

Can somebody provide some pointers to either dependent or alternative
nonce mechanisms?

Given that RFC 3540 conflicts with RE-ECN, what is (your opinion of) the
likely trajectory for RFC 3540?

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

---

From: Neil Spring <[email-masked]>
Date: Thu, 14 Dec 2006 10:31:45 -0500

Matt,

(I'm one of the authors of rfc 3540.)

> to the document, it requires re-issuing the TSVWG LC and possibly  

I don't entirely understand the problem --that RFC 3540 can get  
permission to use a bit in the TCP header but not a code number in a  
statistics MIB seems odd to me.

I don't see much difference; the object could be added again later, no?

> Are there any known implementations of RFC3540 in the field?

None to my knowledge -- I'm assuming "the field" doesn't include my  
little machine. :)

> Can somebody provide some pointers to either dependent or alternative

I think someone else may chime in here.

> likely trajectory for RFC 3540?

In isolation, although I would hope to see RFC 3540 advance to  
proposed standard on its own, a few years of experience suggest that  
it is unlikely to proceed further until motivated by misbehavior in  
the network or until blessed by experience with comparable  
implementations for non-TCP protocols.  (the rest of this note mostly  
restates that point;  this is a good place to stop reading if my  
ramblings on tsvwg don't seem entertaining.)

I have yet to digest more than a page of the RE-ECN draft, so I can't  
yet comment on how "the conflict" changes this trajectory.  As I  
flipped immediately to the section that should contrast the two  
approaches to me, I don't especially like (quoting draft-briscoe- 
tsvwg-re-ecn-tcp-03.txt):

> Delaying the ECN nonce is justified because the applicability of the
>    ECN nonce seems too limited for it to consume a two-bit  
> codepoint in
>    the IP header.

which seems, uhm, misleading if not false.  (The nonce consumes one  
tcp bit in a reserved field that is a small pain to make good use of  
because of the layout of the header structure;  the ECT/CE codepoint  
already required two IP header bits before we started making noise,  
and it has been well-standardized in its ECT(0) and ECT(1) form.  I  
suppose the re-ECN vs ecn nonce conflict is an issue for another  
thread on tsvwg.)

Our intent (speaking for David and David without consent) with RFC  
3450 was to provide to the community with an implementation and  
specification of a mechanism to protect against a new possible threat  
enabled by ECN.  This threat gave receivers more power than they have  
today and would allow buggy receivers or firewalls to "cheat" by  
ignoring ECN marks.   With the ecn nonce, buggy implementations could  
be detected so that transport could revert to the previous, trust-the- 
sender (google) and trust-the-dropping/marking-router (uunet) model  
in which receivers are assumed to want the data enough not to lie  
about loss.

It was urgent, at the time, to propose the mechanism by which the two  
ECT codepoints would be used to allow routers the ability to  
unerasably-mark packets.  However, it remains not urgent to protect  
the network against a threat that probably still doesn't exist *in  
practice* because of painfully slow ECN deployment.   We have the  
(albeit experimental) standard, we have the spec, we have an example  
implementation, all sitting like an antidote in a vault waiting for  
the day some botnet decides to victimize the network by sending  
optimistic or ecn-suppressing acks... one of the few remaining ways  
to get any amplification off remote hosts now that broadcast ping and  
recursive dns are widely disabled.

None of us want to push the ECN nonce for TCP as a juggernaut to  
"displace" any alternative approach -- the community has time to find  
the best plan and allow people to find better schemes or find holes  
in 3540.  If it does prevent other approaches from progressing, it is  
because it solves a restricted, realistic problem with a simple  
technique that can be described in a few pages -- the size of any  
modification to TCP that folks can wrap their heads around.

I think we're unlikely to get "real world" progress on the ECN nonce   
-- or any other ECN-protecting mechanism -- until ECN is actively (by  
a miscreant) or passively (by a widely-deployed faulty firewall)  
attacked.

Matt -  thanks for sending the rfc 3540 authors a note.
-neil