Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt
Bob Briscoe <rbriscoe@jungle.bt.co.uk> Fri, 26 October 2007 17:37 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7p-00073i-Cm; Fri, 26 Oct 2007 13:37:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiuvx-0001Bv-6u for ietf@ietf.org; Fri, 19 Oct 2007 12:42:49 -0400
Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiuvp-0007Ki-QL for ietf@ietf.org; Fri, 19 Oct 2007 12:42:49 -0400
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:42:25 +0100
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:42:25 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1192812144863; Fri, 19 Oct 2007 17:42:24 +0100
Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l9JGfsQW020095; Fri, 19 Oct 2007 17:42:07 +0100
Message-Id: <5.2.1.1.2.20071019165431.018d18c8@pop3.jungle.bt.co.uk>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Fri, 19 Oct 2007 17:41:46 +0100
To: Tom Yu <tlyu@MIT.EDU>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
In-Reply-To: <ldvmyufhlgi.fsf@cathode-dark-space.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.36 () ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 19 Oct 2007 16:42:25.0798 (UTC) FILETIME=[0795B260:01C8126F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:20 -0400
Cc: secdir@MIT.EDU, ietf@ietf.org, bsd@cisco.com, tsvwg-chairs@tools.ietf.org
Subject: Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
Tom, You're analysis of the impact on the ECN nonce is accurate. Below is our reasoning for not including the ECN nonce capability in this proposal... An ECN nonce capability could be provided within the MPLS EXP field by using one more of the 8 available codepoints for each DSCP requiring the facility. This could be defined in a future RFC, because neither our ECN proposal nor the use of the EXP field for Diffserv preclude other uses of the EXP codepoints. Of course, an operator who uses Diffserv & ECN will tend to have to preclude other uses like this by consuming all 8 codepoints, but they do have the option of using Labels for Diffserv (LLSP), which leaves more space in the EXP field for ECN & ECN nonces. However, we decided not to bundle the ECN nonce into this proposal, as it would have required extra standards text with little chance of it being used - the RFC3540 ECN nonce has been experimental status since Jun 2003 and there have been no implementations. But we haven't precluded an MPLS ECN nonce being added later. In particular, it would be very unlikely that an operator would use up one more of its scarce MPLS EXP codepoints to validate that its own LSRs weren't removing markings added by other LSRs in the same MPLS tunnel (whether maliciously or accidentally). The case for the ECN nonce is much stronger as a protection against misbehaving receivers than network nodes - particularly given MPLS protection would typically only protect one domain from itself. But even then, the ECN nonce only enables a *data sender* to establish whether congestion notifications have been removed. If a network operator wanted to use the ECN nonce as proposed to detect removal of congestion notifications, it would have to trust data senders to act on its behalf. Counter to what I've just said about only the sender being able to use the nonce, Sally Floyd suggested on the tsvwg list (can't find it at the mo) that a tunnel egress could use an ECN nonce-like capability to check if the nonce in the outer was different to that in the inner, which would imply a congestion marking had been removed. This would certainly work, but only if the tunnel ingress encrypted the inner nonce - otherwise whoever removed an outer notification could just reset the outer header back to what it used to be by reading the inner header. Having started to invent more complicated possible uses of something that already wasn't used, we decided not to spend too much more time on this, given we weren't precluding someone doing all this later. Bob At 03:44 19/10/2007, Tom Yu wrote: >This is a review of draft-ietf-tsvwg-ecn-mpls-02.txt. > >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >I am not very familiar with MPLS or Diffserv, but I did read some of >the cited MPLS and ECN references in order to understand this >document. > >I mostly agree with the claim in the Security Considerations that this >proposal introduces no additional vulnerabilities. However, although >this document indicates that using a RFC3540 ECN nonce to detect >misbehaving receivers continues to work under this proposal, a RFC3540 >nonce can also be used to detect disruption of the end-to-end >continuity of ECN signaling. This proposal can compromise the >detection of disruptions of end-to-end ECN signaling continuity which >occur within a given MPLS domain. I lack the context to determine >whether this is a serious problem. > >The procedure described in RFC3540 relies on the existence of two >distinct ECT indications to convey a single bit's worth of nonce data >to the receiving transport endpoint. This proposal functionally uses >only a single bit to indicate a CM state. If a malicious or >malfunctioning element within the MPLS domain clears a CM state set by >some LSR, the egress LSR will not set the CE state in the >unencapsulated IP packet. Consequently, the receiving transport >endpoint acts as if the packet did not have a CE state marked at all, >and the sending transport endpoint receives no indication that a >problem exists with end-to-end ECN signaling. > >In effect, the MPLS domain behaves as a single black box router from >the perspective of RFC3540, masking any ECN signaling anomalies >internal to the MPLS domain. This may be an acceptable consequence of >this proposal, but it would be useful to know whether this consequence >has been considered. > >---Tom ____________________________________________________________________________ Bob Briscoe, <bob.briscoe@bt.com> Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf