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

["George Swallow (swallow)" <[e-mail]>]

Lizhong, Adrian - 

Inline -

On 6/17/15 2:28 PM, "Adrian Farrel" <[e-mail]> 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.

GS> Sent mail giving up my rights.  Need to get Tom as well.
>
>>> 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."

GS> Agree.
> 
>> [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.

GS> Indeed.  One of the applications here is to trace only so that you can
successfully ping.
>
>>> 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.

GS>  I made such a change awhile back.  It got shot down on the list.
There was push back due to the requirement for topological awareness
within the LSP Ping module.

Adrian - If you want to try pushing back on that, would you send a message
to the list on just this topic and see if we can convince folks.

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

GS> Adrian - what you say about what the receiver will do is spot on.
However, there is no guarantee that it will be routable back to the source

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

GS> This is a good thing to include.

Thanks for the review.

George
>
>Cheers,
>Adrian
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls