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

["Lizhong Jin" <[e-mail]>]

Thank you all for the help. We will update accordingly in the next version.

Regards
Lizhong

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: 2015年6月25日 15:48
> To: thomas nadeau; [e-mail]
> Cc: George Swallow (swallow); [e-mail]; 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
> 
> Lizhong,
> 
> It should be safe to remove the pre-RFC5378 disclaimer. I will address the
issue
> in the shepherds write-up.
> 
> /Loa
> 
> On 2015-06-24 12:02, thomas nadeau wrote:
> >
> >
> >
> >
> >> 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]
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]