Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT)

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

Hi Mirja,

Is there a rational for
copying this ICMP hack?

<Nagendra> Using a flag in the header and sending it hop-by-hop will end up taking soft path (CPU punt path) and may not validate the actual data path. Use of TTL trick will help validate if the transit nodes are forwarding it as per control plane. With this machinery, we get the Downstream TLV details as per control plane, include it in the next probe  and validate it with the actual Downstream node.

Thanks,
Nagendra

From: "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 26, 2016 at 1:26 AM
To: Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT)
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Nagendra Kumar Nainar <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Wednesday, October 26, 2016 at 1:26 AM

Hi, Mirja,

Thanks, please see inline.

On Oct 25, 2016, at 11:17 AM, Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mpls-rfc4379bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few not very important comments:

1) To me it seems a bit unfortunate that this draft points to rfc6425 and
rfc6426 for the definition of the T and R flags, given the goal was to
have all specifications in one doc. Not sure if that can or should be
fixed. Just wanted to mention it.

Thanks for mentioning it. The WG did discuss this. You can see https://www.ietf.org/proceedings/96/slides/slides-96-mpls-2.pdf

Since 4379bis is not obsoleting rfc6525 and rfc6526, the idea was to keep the definition in those RFCs, but mention them in the bis.


2) I would expect that the security section recommends border filtering
of MPLS ping message, given that these are usually used within one
domain, no?


There is inter-as and inter domain lsp ping.

3) I know this is a bis doc but I'm still wondering why this TTL trick is
used here. For ICMP that was a way that utilizes the existing
specification and implementation to get further information.

Here, the TTL expiration in traceroute mode is used to intercept the packet and send it to the control plane. Additionally see below.

However
here, you could just have used a flag in the header either saying 'only
forward to the end' or 'reply and still forward', or something like this,
to cover the two modes. This would also allow to just send one packet to
the end instead of sending one for each hop.

That's a great question for RFC4379, but not for the bis :-) Could have done a lot of things at the time.

A major departure from the existing paradigm, and a potentially nice attack vector, would be to generate multiple response packets from a single packet. But nonetheless, that would be a different protocol and not a bis.

Is there a rational for
copying this ICMP hack?


Hack for one, elegant engineering for another, maybe both :-)

Thanks,

- Carlos.