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

[thomas nadeau <[e-mail]>]

> On Jun 24, 2015, at 4:32 AM, Loa Andersson <[e-mail]> 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" <[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.
>>> 
>>> [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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
> 
> -- 
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]