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

["Adrian Farrel" <[e-mail]>]

I'm fine with all this. Thanks.
 
See follow-up to catch one of George's points.
 
Adrian
 
From: [e-mail] [mailto:[e-mail]] 
Sent: 18 June 2015 10:46
To: adrian; loa; mpls; mpls-chairs; draft-ietf-mpls-lsp-ping-relay-reply; db3546
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
 
Hi Adrian,
Thanks for the reply. Please see inline below.
 
  _____  

Regards
Lizhong
 
From: Adrian Farrel <mailto:[e-mail]> 
Date: 2015-06-18 02:28
To: [e-mail]; 'loa' <mailto:[e-mail]> ; 'mpls' <mailto:[e-mail]> ; 'mpls-chairs' <mailto:[e-mail]> ; 'draft-ietf-mpls-lsp-ping-relay-reply' <mailto:[e-mail]> ; 'db3546' <mailto:[e-mail]> 
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
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."
[Lizhong] accepted.
 
[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.
[Lizhong] OK, then we could add the following in section 4 to avoid misunderstanding:
In the following section, we describe the relay reply procedures with traceroute 
operation. If operator has knowledge of the relay nodes, the initiator could do LSP 
Ping by directly sending Echo Request with Relay Node Address Stack TLV 
containing the already known relay nodes.
 
[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.
[Lizhong] yes, we use "SHOULD" to make the requirement. See below description in section 4.2:
If a node spans two addressing domains (with respect to this 
message) where nodes on either side may not be able to reach nodes in the 
other domain, then the final address added SHOULD set 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.
[Lizhong] Are you referring the case when the receiver receives Echo Request? In that
case, yes, it will respond without including the TLV. It is a sub-case of case 1. And I
will add the following in the first case:
If the receiver does not recognize the Relay Node Address Stack TLV, as per 
section 3 and 4.5 of [RFC4379], it will send an Echo Reply without including the TLV.
If you are referring the case when the receiver receives Relayed Echo Reply, if it could
not understand the TLV, it will also not understand the message type "Relayed Echo Reply".
So the packet will be dropped.
 
>> 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.
[Lizhong] If one router's control plane in the network is hijacked, it could send any 
information to the third party. It is a general problem. But I understand you concern.
I will add the following to try to mitigate your concern.
The Relay Node Address Stack TLV has the path information of the LSP, and 
such information may be maliciously used by any uncontrolled LSR/LER. We have
two ways to reduce the path information in the TLV:
1. it is recommended to clear the K bit in the relay address entry unless you have to.
2. it is encouraged to use NIL address entry to hide node information if possible.
 
Cheers,
Adrian