Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
Loa Andersson <loa@pi.nu> Thu, 25 June 2015 07:47 UTC
Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6121B316B for <mpls@ietfa.amsl.com>; Thu, 25 Jun 2015 00:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAeQ9BFGGZBu for <mpls@ietfa.amsl.com>; Thu, 25 Jun 2015 00:47:33 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9711B2BAE for <mpls@ietf.org>; Thu, 25 Jun 2015 00:47:33 -0700 (PDT)
Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7B1D018013E2; Thu, 25 Jun 2015 09:47:31 +0200 (CEST)
Message-ID: <558BB212.5040303@pi.nu>
Date: Thu, 25 Jun 2015 09:47:30 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: thomas nadeau <tnadeau@lucidvision.com>, "lizho.jin@gmail.com" <lizho.jin@gmail.com>
References: <D1AEF31A.3B607%swallow@cisco.com> <558A6B2A.9010000@pi.nu> <334FDAB8-48A3-40CC-A4A4-DB414F53EAD5@lucidvision.com>
In-Reply-To: <334FDAB8-48A3-40CC-A4A4-DB414F53EAD5@lucidvision.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/f2q-aYFALrfaO-x8T5SciJrJ3G8>
Cc: mpls <mpls@ietf.org>, draft-ietf-mpls-lsp-ping-relay-reply <draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org>, mpls-chairs <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 07:47:36 -0000
Lizhong, It should be safe to remove the pre-RFC5378 disclaimer. I will address the issue in the shepherds write-up. /Loa On 2015-06-24 12:02, thomas nadeau wrote: > > > > >> On Jun 24, 2015, at 4:32 AM, Loa Andersson <loa@pi.nu> wrote: >> >> George, >> >> I sympathize with this, but as I recall it the current document is the >> result of a merger between two earlier drafts: >> >> draft-ietf-mpls-interas-lspping (first version posted March 2007) and >> that one goes back to draft-nadeau-mpls-interas-lspping (first version >> posted July 2005). >> and >> draft-zj-mpls-lsp-ping-reply-relay (first version posted October 2011) >> >> RFC 5378 was published Oct 2008, to be on the safe side any work that >> pre-dates RFC 5378 should have the "pre-RFC5378 disclaimer". So draft-zj >> is in the clear. >> >> However, since both draft-ietf-mpls-interas-lspping and >> draft-nadeau-mpls-interas-lspping predates RFC 5378, we need the >> pre-RFC5378 disclaimer unless both authors of the two draft grant their >> rights to the IETF trust. My straw man advice would be to try to remove >> the pre-RFC5378 disclaimer based on statements from both authors. >> >> George does so in the mail below. >> >> Tom are you willing to do so also? > > yes i agree. > >> >> /Loa >> >> >>> On 2015-06-23 17:30, George Swallow (swallow) wrote: >>> Lizhong - >>> >>> If there's any text left from the original draft, then it belongs to >>> either me or Tom. I hereby surrender my rights. >>> >>> Tom? >>> >>> George >>> >>>> On 6/17/15 2:28 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote: >>>> >>>> Lizhong, >>>> >>>> Apologies, I fumbled your response. >>>> >>>> I snipped out the stuff we agree on. >>>> >>>>> Thank you for the review. Please see my reply inline below. Correct me >>>>> if other authors have different opinion. >>>>> >>>>> I will update the draft after the end of last call. >>>> >>>>>> Just being a good citizen and reviewing this I-D during WG last call. >>>>>> I didn't have much time so I only found a number of nits most of which >>>>>> are probably not significant. >>>>>> --- >>>>>> >>>>>> idnits notes the presence of a pre-RFC5378 disclaimer. Do you really >>>>>> need that? >>>>>> [Lizhong] this may need the answer from chairs and AD. We only follow >>>>>> the rules. >>>> >>>> If you are following the rules, that's fine. I think the rules are that >>>> you only >>>> need to include the disclaimer if text included in the document was >>>> written >>>> before the date of RFC 5378 and if at least one of the authors of the >>>> text has >>>> not given up their copyright as described in that RFC. >>>> >>>> [snip] >>>> >>>>>> Section 4.1 >>>>>> >>>>>> The source UDP port field MUST be set >>>>>> to the source UDP port. >>>>>> >>>>>> There is no "source UDP port" field. Perhaps the "Initiator Source >>>>>> Port" >>>>>> field? >>>>>> >>>>>> But also, this text is quite confusing. The text in 3.2 is much >>>>>> clearer. >>>>> [Lizhong] yes, should be: >>>>> The source UDP port field MUST be set to the initiator source port. >>>> >>>> Hmmm, I think... >>>> >>>> "The Initiator Source Port field MUST be set to the source UDP port." >>>> >>>> [snip] >>>> >>>>> [Lizhong] traceroute is not mandatory before ping. If operator has >>>>> knowledge >>>>> of the relay nodes, the initiator could directly send ping with Relay >>>>> Node >>>>> Address Stack TLV containing the already known relay nodes. >>>> >>>> That would make a valuable addition to 4.1, as well. >>>> >>>> [snip] >>>> >>>>>> I tried to work out how things would pan out if two ASes on the path >>>>>> used the same address space within their AS. Would an address appear in >>>>>> the stack and seem to be routable when it is really an address in the >>>>>> other AS? >>>>> [Lizhong] we have an example in section 5. And address of P1 and P2 >>>>> could be >>>>> same. In that case, ASBR1 must adds its interface address facing ASBR2 >>>>> with >>>>> the K bit set. Then relay reply will not be miss-routed. >>>> >>>> Ah, I get it. >>>> But this relies on ASBT1 setting the K bit. >>>> So I suspect this needs to not be a special case: you need to require >>>> that the >>>> domain boundary always sets the K bit. >>>> >>>> [snip] >>>> >>>>>> The third case in 4.5 is when the receiver does not understand the TLV >>>>>> and ignores it. In this case it will send an Echo Reply without itself >>>>>> including the TLV. >>>>> [Lizhong] the receiver is unable to send the Echo Reply, because it does >>>>> know the destination IP address and UDP port number. So if the receiver >>>>> could not understand the TLV, then the relay message will be dropped. >>>> >>>> Section 4.5 of 4379 says: >>>> >>>> The destination IP address and UDP port are copied from the >>>> source IP address and UDP port of the echo request. >>>> >>>> That is what the legacy receiver will attempt to do. It doesn't matter >>>> whether >>>> the optional Relay Node Address Stack TLV is in the echo request message >>>> or not, >>>> the legacy node will follow 4379. So it *will* be able to respond. >>>> >>>>>> Section 6 should note that the new TLV provides a way for Echo Reply >>>>>> messages to be diverted so that information can be collected. For >>>>>> example, if a stack entry can be inserted, the Echo Reply messages can >>>>>> be caused to transit another AS unrelated to the LSP under test. Since >>>>>> the Echo Reply reveals path information about the LSP, this is a >>>>>> valuable attack. Having said that, you can say how this TLV is >>>>>> protected in the Echo Reply message. >>>>> >>>>> [Lizhong] Do you mean the new TLV could be used to collect path >>>>> information >>>>> unrelated to the LSP under test? This is not true. Only the node along >>>>> the >>>> LSP >>>>> will add path information into the new TLV. The relay node in the new >>>>> TLV >>>>> will only relay the Echo Reply to the initiator, and will not add >>>>> information >>>> to >>>>> the new TLV. >>>> >>>> I think you misunderstand how security attacks might work. Suppose I am >>>> able to >>>> do one of two things: >>>> 1. Modify the control plane code on a router that adds or processes a >>>> Relay Node Address Stack TLV so that it adds a bogus entry to the >>>> TLV. The prospect of modifications to control plane code is generally >>>> considered to be so disastrous that it is just noted without any >>>> further precautions (after all, if you can get at the control plane >>>> code, you can make the routers do anything). >>>> 2. Intercept and modify a packet in transit. This is the main risk I am >>>> talking about. >>>> >>>> Cheers, >>>> Adrian >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
- [mpls] MPLS working group last call on draft-ietf… Loa Andersson
- Re: [mpls] MPLS working group last call on draft-… Adrian Farrel
- Re: [mpls] MPLS working group last call on draft-… lizho.jin@gmail.com
- [mpls] Closed - MPLS working group last call on d… Loa Andersson
- Re: [mpls] MPLS working group last call on draft-… lizho.jin@gmail.com
- Re: [mpls] MPLS working group last call on draft-… Adrian Farrel
- Re: [mpls] MPLS working group last call on draft-… lizho.jin@gmail.com
- Re: [mpls] MPLS working group last call on draft-… George Swallow (swallow)
- Re: [mpls] MPLS working group last call on draft-… George Swallow (swallow)
- Re: [mpls] MPLS working group last call on draft-… Loa Andersson
- Re: [mpls] MPLS working group last call on draft-… thomas nadeau
- Re: [mpls] MPLS working group last call on draft-… Loa Andersson
- Re: [mpls] MPLS working group last call on draft-… Lizhong Jin
- Re: [mpls] MPLS working group last call on draft-… Adrian Farrel
- Re: [mpls] MPLS working group last call on draft-… Adrian Farrel
- Re: [mpls] MPLS working group last call on draft-… lizho.jin@gmail.com