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