Subject: Re: [Last-Call] Last Call Comment: <draft-ietf-detnet-ip-05.txt>- ICMP support, e.g., ping and traceroute

From: Balázs Varga A <[email-masked]>
Date: Fri, 17 Apr 2020 13:03:53 +0000

Hi David,

Thanks for the comment. I am working on the update of the document.

In order to fix your comment I propose to add a new paragraph in Section
3. after your referred text dealing with 6-tuple.
NEW
    For some of the protocols 5-tuples and 6-tuples cannot be used because 
    the port information is not available (e.g., ICMP, IPSec ESP). Same can 
    be valid for flow aggregates. In such cases using smaller tuples are 
    appropriate, e.g., a 3-tuple (2 IP addresses, IP protocol) or even a 
    2-tuple (all IP traffic between two IP addresses).
END

Furthermore to change text in Section 5.1.2 (adding ICMP):
OLD
   Implementations of this document MUST support DetNet flow
   identification based on header information identified in this
   section.  Support for TCP, UDP and IPsec flows is defined. Future
   documents are expected to define support for other protocols.
NEW
   Implementations of this document MUST support DetNet flow
   identification based on header information identified in this
   section.  Support for TCP, UDP, ICMP and IPsec flows is defined. Future
   documents are expected to define support for other protocols.
END

And finally adding a new subsection before current 5.1.2.2.
NEW
    5.1.2.2 ICMP
        DetNet flow identification for ICMP is achieved based on the 
        protocol's header. All ICMP types MUST be supported. 
END

Do they address your comments?

Cheers
Bala'zs

-----Original Message-----
From: Black, David <[email-masked]> 
Sent: Tuesday, March 17, 2020 1:39 AM
To: Lou Berger <[email-masked]>; [email-masked]
Cc: Ethan Grossman <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Black, David <[email-masked]>
Subject: RE: Last Call Comment: <draft-ietf-detnet-ip-05.txt>- ICMP support, e.g., ping and traceroute

Hi Lou,

> Umm, what makes you say ICMP isn't supported?  The current text has 
> what you are asking for:
> 
> https://tools.ietf.org/html/draft-ietf-detnet-ip-05#section-5.1.1.3
> (which is also summarized in section 6)
> 
> There's additional information that can be specified when the next 
> protocol is UDP/TCP/IPsec, but ICMP is perfectly valid in the current 
> flow definition.

I stand corrected - the current draft's requirement for ICMP support is "MAY" - that requirement ought to be a "MUST" now to ensure that ping and traceroute will work for all DetNet implementations.

The details of why ICMP support is a "MAY" requirement in the current draft begin with the summary in Section 6 (this is the IPv4 text; the IPv6 text is analogous):

   o  IPv4 protocol field.  A limited set of values is allowed, and the
      ability to ignore this field, e.g., via configuration of the value
      zero (0), is desirable.

So, what is that "limited set of values"?  Section 5.1.1.3 says:

   Implementations of this document MUST support DetNet flow
   identification based on the IPv4 Protocol field when processing IPv4
   packets, and the IPv6 Next Header Field when processing IPv6 packets.
   An implementation MUST support flow identification based on the next
   protocol values defined in Section 5.1.2.  Other, non-zero values,
   MUST be used for flow identification.  Implementations SHOULD allow
   for these fields to be ignored for a specific DetNet flow.

Moving to Section 5.1.2, the text that defines the required next protocol values is:

   Implementations of this document MUST support DetNet flow
   identification based on header information identified in this
   section.  Support for TCP, UDP and IPsec flows is defined. Future
   documents are expected to define support for other protocols.

ICMP is not listed, so this falls back to Section 5.1.1.3 where ICMP is included in: "Other, non-zero values, MUST be used for flow identification."  That text doesn't say which non-zero values, effectively leaving the choice to implementers.   That's a truck-sized loophole ... looking at the IANA registry (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1), an implementer could select 12 (PUP) and 16 (Chaos) and claim to have met that requirement :-).

The upshot is that ICMP is sufficiently important that support for it ought to be a MUST requirement now, not left as something for a future document to do, potentially stranding implementations whose implementers didn't think of ICMP until it was too late.

Once ICMP is mandatory, the next consideration is whether that support in flow identification is all-or-nothing across ICMP types vs. whether DetNet flow identification ought to be able to select specific ICMP types.   There are about a dozen currently defined valid ICMP types (https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types), some of which can be used to cause mischief.  OTOH, a DetNet network is a tightly controlled environment, so it may suffice to simply require all-or-nothing support for ICMP types in DetNet flow identification and rely on other controls to prevent mischief.  A good and carefully thought out decision needs to be made on this topic, as it may affect implementation hardware.

Beyond that, Section 3 focuses on 6-tuple identification:

   The DetNet IP data plane primarily uses "6-tuple" based flow
   identification, where 6-tuple refers to information carried in IP and
   higher layer protocol headers.  The 6-tuple referred to in this
   document is the same as that defined in [RFC3290].  Specifically
   6-tuple is (destination address, source address, IP protocol, source
   port, destination port, and differentiated services (DiffServ) code
   point (DSCP).  General background on the use of IP headers, and
   5-tuples, to identify flows and support Quality of Service (QoS) can
   be found in [RFC3670].  [RFC7657] also provides useful background on
   the delivery of DiffServ and "tuple" based flow identification.  Note
   that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
   component.

   The DetNet IP data plane also allows for optional matching on the
   IPv6 flow label field, as defined in [RFC8200].

This is where I initially went astray in writing up the comment - Section 3 also ought to point out that smaller tuples are fine, e.g., a 3-tuple (2 IP addresses, IP protocol) or even a 2-tuple (all IP traffic between two IP addresses) are both possible and reasonable under the right circumstances.  In addition, ICMP is one of two protocols for which 5-tuples and 6-tuples cannot be used because the port information is not available - the other protocol is IPsec ESP, which encrypts the transport header that contains the ports.   All of this would be very helpful to summarize in Section 3.

> The IP OAM document is coming.  In hallway discussion we even talked 
> about how to make ICMP/BFD/etc follow the same paths as other specific 
> flow rules.  There is a nascent document on this, 
> draft-mirsky-detnet-ip-oam, although it is certainly lagging behind 
> the MPLS oam document.  FWIW I'm hoping for there to be more who wish 
> to contribute on the IP OAM document - hint, hint, hint...

Greg twisted my arm (gently), so I've signed on to help with that IP OAM draft.

Thanks, --David

> -----Original Message-----
> From: Lou Berger <[email-masked]>
> Sent: Sunday, March 15, 2020 5:29 PM
> To: Black, David; [email-masked]
> Cc: Ethan Grossman; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: Last Call Comment: <draft-ietf-detnet-ip-05.txt>- ICMP 
> support, e.g., ping and traceroute
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> 
> See below.
> 
> On 3/12/2020 11:06 AM, Black, David wrote:
> > Comment: As specified in the current draft, the DetNet IP data plane 
> > does not
> support ping, traceroute, and any other mechanism or tool that is 
> based on ICMP.  This is because ICMP does not use ports, so ICMP 
> traffic cannot be described by either a 5-tuple or a 6-tuple, and hence ICMP traffic cannot be
> part of a DetNet flow that is described by a 5-tuple or 6-tuple.   The draft needs
> to be revised to either:
> > 	- enable ICMP to be used with the DetNet IP data plane (ICMP would
> use a 3-tuple, two IP addresses and the protocol number for ICMP); or
> > 	- document and justify a deliberate design decision that ICMP (and
> hence ICMP-based tools) cannot be used with the DetNet IP data plane.
> > The former course of action (enable ICMP with the DetNet IP data 
> > plane) is
> strongly suggested, e.g., in order to enable use of ping and 
> traceroute with the DetNet IP data plane.
> 
> Umm, what makes you say ICMP isn't supported?  The current text has 
> what you are asking for:
> 
> https://tools.ietf.org/html/draft-ietf-detnet-ip-05#section-5.1.1.3
> (which is also summarized in section 6)
> 
> There's additional information that can be specified when the next 
> protocol is UDP/TCP/IPsec, but ICMP is perfectly valid in the current 
> flow definition.
> 
> > Background: In discussion at the Singapore detnet WG meeting, OAM 
> > was
> characterized as something that would be added to the DetNet data 
> planes later, with the (at least implied) assertion that there 
> shouldn't be anything in the data planes that blocks OAM 
> functionality.  That does appear to be the case for the MPLS data plane, but the IP data plane appears to differ.
> 
> The IP OAM document is coming.  In hallway discussion we even talked 
> about how to make ICMP/BFD/etc follow the same paths as other specific 
> flow rules.  There is a nascent document on this, 
> draft-mirsky-detnet-ip-oam, although it is certainly lagging behind 
> the MPLS oam document.  FWIW I'm hoping for there to be more who wish 
> to contribute on the IP OAM document - hint, hint, hint...
> 
> > Later than might have been ideal, I've discussed DetNet IP OAM with 
> > Greg
> Mirsky via email - our initial take from that discussion is that most 
> OAM for the DetNet IP data plane can be accomplished over UDP, with the notable
> exception of tools such as ping and traceroute that use ICMP.   For ping and
> traceroute to work with DetNet, the ICMP packets that are used have to 
> pass through the DetNet data plane at DetNet nodes, otherwise these 
> tools may erroneously report no connectivity problems with the 
> ordinary (non-DetNet) data plane when DetNet IP data plane connectivity is broken and vice-versa.
> 
> Right -- and this can be done as part of the flow rules setup that is 
> outside the scope of this document.
> 
> > Sorry to bring this up at a late stage in the process, but better late than never.
> 
> Not at all, this has been discussed but has yet to make it in WG 
> documents, so is 100% fair game.  The intent is for the current 
> documents to support the future OAM work.  It would have been optimal 
> for the OAM documents to be done now, but their not as contributions 
> in this area have lagged behind the more general data plane work.  
> Again, contributions in this are would be hugely welcomed!
> 
> 
> >
> > I also spotted an editorial oversight in Section 4.3.1:
> >
> > OLD
> >     Class of Service (CoS) for DetNet flows carried in IPv6 is provided
> >     using the standard differentiated services code point (DSCP) field
> >     [RFC2474] and related mechanisms.
> > NEW
> >
> >     Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is provided
> >     using the standard differentiated services code point (DSCP) field
> >     [RFC2474] and related mechanisms.
> >
> > The authors deserve some sort of recognition here, as the far more 
> > typical
> variant of this oversight is to omit IPv6 :-)
> 
> Thanks ;-)
> 
> Lou
> 
> (as contributor)
> 
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: IETF-Announce <[email-masked]> On Behalf Of 
> >> The
> IESG
> >> Sent: Friday, February 28, 2020 3:59 PM
> >> To: IETF-Announce
> >> Cc: Ethan Grossman; [email-masked]; [email-masked]; 
> >> [email-masked]; [email-masked]
> >> Subject: Last Call: <draft-ietf-detnet-ip-05.txt> (DetNet Data 
> >> Plane: IP) to Proposed Standard
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >>
> >> The IESG has received a request from the Deterministic Networking 
> >> WG
> >> (detnet)
> >> to consider the following document: - 'DetNet Data Plane: IP'
> >>    <draft-ietf-detnet-ip-05.txt> as Proposed Standard
> >>
> >> The IESG plans to make a decision in the next few weeks, and 
> >> solicits final comments on this action. Please send substantive 
> >> comments to the [email-masked] mailing lists by 2020-03-13. 
> >> Exceptionally, comments may be sent to [email-masked] instead. In 
> >> either case, please retain the beginning of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>
> >>
> >>     This document specifies the Deterministic Networking data plane when
> >>     operating in an IP packet switched network.
> >>
> >>
> >>
> >>
> >> The file can be obtained via
> >> https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/
> >>
> >> IESG discussion can be tracked via
> >> https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ballot/
> >>
> >>
> >> No IPR declarations have been submitted directly on this I-D.
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> IETF-Announce mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Apr 2020 09:15:41 -0400

Hi,

David -- looks like I missed your response to my message.  My apologies.

Balázs -- Thanks for the changes and agree that it is a good adjustment 
to address David's changes.  One more suggestion to allow for a possible 
future definition that allows for type-specific flows - if anyone 
decides that such is a good thing:

     s/All ICMP types MUST be supported/Note that ICMP type is not 
included in the flow definition/

Lou

On 4/17/2020 9:03 AM, Balázs Varga A wrote:
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Black, David" <[email-masked]>
Date: Fri, 17 Apr 2020 23:31:45 +0000

Lou and Balazs,

This looks good.

Coincidentally, after reading the initial proposed text, my initial reaction was along the same lines as Lou's - I was concerned that the "MUST" to support all ICMP types could be misinterpreted as requiring DetNet to forward ICMP packets with types that need to be prohibited for other potentially unrelated reasons.   Lou's suggested rephrase to state that ICMP type is not part of the DetNet flow definition deals with that in a fine fashion, so please do pick up that change ... and I do see that it is in the pull, along with text to indicate that it's fine to use tuples that are smaller than 5-tuples and 6-tuples.

Thanks, --David

> Sent: Friday, April 17, 2020 9:16 AM
> To: Balázs Varga A; Black, David; [email-masked]
> Subject: Re: [Detnet] Last Call Comment: <draft-ietf-detnet-ip-05.txt>- ICMP
> > Cc: Ethan Grossman <[email-masked]>; [email-masked]; draft-ietf-detnet-
> [email-masked]; [email-masked]; [email-masked]; Black, David
> <[email-masked]>
> > I stand corrected - the current draft's requirement for ICMP support is "MAY"
> - that requirement ought to be a "MUST" now to ensure that ping and
> traceroute will work for all DetNet implementations.
> >
> > The details of why ICMP support is a "MAY" requirement in the current draft
> begin with the summary in Section 6 (this is the IPv4 text; the IPv6 text is
> analogous):
> >
> > ICMP is not listed, so this falls back to Section 5.1.1.3 where ICMP is included
> in: "Other, non-zero values, MUST be used for flow identification."  That text
> doesn't say which non-zero values, effectively leaving the choice to
> implementers.   That's a truck-sized loophole ... looking at the IANA registry
> (https://www.iana.org/assignments/protocol-numbers/protocol-
> numbers.xhtml#protocol-numbers-1), an implementer could select 12 (PUP)
> and 16 (Chaos) and claim to have met that requirement :-).
> >
> > The upshot is that ICMP is sufficiently important that support for it ought to
> be a MUST requirement now, not left as something for a future document to
> do, potentially stranding implementations whose implementers didn't think of
> ICMP until it was too late.
> >
> > Once ICMP is mandatory, the next consideration is whether that support in
> flow identification is all-or-nothing across ICMP types vs. whether DetNet flow
> identification ought to be able to select specific ICMP types.   There are about a
> dozen currently defined valid ICMP types
> (https://www.iana.org/assignments/icmp-parameters/icmp-
> parameters.xhtml#icmp-parameters-types), some of which can be used to
> cause mischief.  OTOH, a DetNet network is a tightly controlled environment,
> so it may suffice to simply require all-or-nothing support for ICMP types in
> DetNet flow identification and rely on other controls to prevent mischief.  A
> good and carefully thought out decision needs to be made on this topic, as it
> may affect implementation hardware.
> >
> > This is where I initially went astray in writing up the comment - Section 3 also
> ought to point out that smaller tuples are fine, e.g., a 3-tuple (2 IP addresses, IP
> protocol) or even a 2-tuple (all IP traffic between two IP addresses) are both
> possible and reasonable under the right circumstances.  In addition, ICMP is
> one of two protocols for which 5-tuples and 6-tuples cannot be used because
> the port information is not available - the other protocol is IPsec ESP, which
> encrypts the transport header that contains the ports.   All of this would be very
> helpful to summarize in Section 3.
> >