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

[Loa Andersson <[e-mail]>]

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?

/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]