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

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

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