Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply

thomas nadeau <> Wed, 24 June 2015 10:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB7BF1B34A0 for <>; Wed, 24 Jun 2015 03:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aMOyQx5_fX2T for <>; Wed, 24 Jun 2015 03:02:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F3D91B349F for <>; Wed, 24 Jun 2015 03:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1435140152; bh=x4uC/dEOPkdLZJBIJhV0GKc51+UhBcplvYCs2ipN5R0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=vK+basJ7RZD1O5ReK/3D7xI/+VCZ1fpkuIuDiJi3YatMNlJWpyz5tsYXMQBv66e7V N9CHJV83kECpeW8OdZI3wlMJWP7E2K1t4e9al4XEArDkXV+9X38lDQnJglsr9w8m1l vv1/Q72cUEK2Q0xyGAaMUZFqO5nvFu6mGGSQ0/KE=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: thomas nadeau <>
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <>
Date: Wed, 24 Jun 2015 06:02:25 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: Loa Andersson <>
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=
X-IP-stats: Notspam Incoming Last 0, First 1, in=11, out=0, spam=0 Known=true ip=
Archived-At: <>
Cc: mpls <>, draft-ietf-mpls-lsp-ping-relay-reply <>, "" <>, mpls-chairs <>
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jun 2015 10:02:53 -0000

> On Jun 24, 2015, at 4:32 AM, Loa Andersson <> 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" <> 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
> -- 
> Loa Andersson                        email:
> Senior MPLS Expert                
> Huawei Technologies (consultant)     phone: +46 739 81 21 64