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

"Adrian Farrel" <> Wed, 17 June 2015 18:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 89D011A0248 for <>; Wed, 17 Jun 2015 11:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id faco_kDeKf8o for <>; Wed, 17 Jun 2015 11:28:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29C501A1A79 for <>; Wed, 17 Jun 2015 11:28:09 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t5HIS31M006913; Wed, 17 Jun 2015 19:28:03 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t5HIS2Hu006861 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2015 19:28:02 +0100
From: Adrian Farrel <>
To:, 'loa' <>, 'mpls' <>, 'mpls-chairs' <>, 'draft-ietf-mpls-lsp-ping-relay-reply' <>, 'db3546' <>
References: <>, <04a101d09fad$72a48e90$57edabb0$> <>
In-Reply-To: <>
Date: Wed, 17 Jun 2015 19:28:01 +0100
Message-ID: <0cc101d0a92b$58745050$095cf0f0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQH7JukJl6LbO+JE5C9I+Kw0QjOnSgJFwoxaAlvX4+OdNu44UA==
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--25.424-10.0-31-10
X-imss-scan-details: No--25.424-10.0-31-10
X-TMASE-MatchedRID: x2HXvaraFomI0KPyMNrNUrmR+C0l9vjVUCxD7k+Cw/mqvcIF1TcLYBXZ d5aUtHTKT+8v17QjdI15d3Ro27TECKDUMTFlJZ9NF6z9HGHKwNsg0L4Xy2OHlUENV4Lwnu7BIE9 v7dw1ta7oGnE2x4Id30loJ8LfoLNeEOzOm+YWcCgSuhBXNJb1dG79evoIpeI3FJfW7wEu1kDoZD Q1tC1GDx9YKo6ckKOmeKoBDqrUBc+R8u6DOJbzp4b9ftid8kBcbfVFVoam0SHTXj4xOnxHE1eZo NHWSLwjSSe38b41i5+xkc/e+t764ytg+qZmq1X/+IHpXFbQo2IQ2zDF7O7/jv0YXg59YwMhlDgV 9tdYJkmSsEBqvJTOXhwRzBpiOwjaIBC3pqger3pPuMJi/ZAk8XH9gj5nlAmS3XgCp7wTMXyzi0A Q4R+iwYwREwf0o96Dw6buSFK7/mT1s8eCOeeiYLiMC5wdwKqdDNXyKfpIUCMs7eP5cPCWQzZPIF luSlJ1R4jGP3SnPX8sFqxeblbzZBnsS71Oo/Hw1yMJs9mBCcVp+f1SLTFieuQydRUvl3QTGO0AR gydnVoqiQjTu5MEk5TdOLRTslTI8M+w5/vTMr2eAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5d 3cxkNQP90fJP9eHt
Archived-At: <>
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, 17 Jun 2015 18:28:14 -0000


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.


>> 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."
> [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.


>> 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.
>> 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
> 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
> 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.