Subject: RE: New Version Notification for draft-herbert-6man-icmp-limits-02.txt

From: Ron Bonica <[email-masked]>
Date: Mon, 1 Jan 2018 23:33:45 +0000

Hi Tom,

Thanks for posting this draft. I generally support it, but have one question.

Regarding the Unrecognized Next Header Type (Code 1), you say:

"[RFC8200] specifies that a destination host should send an  "unrecognized next header type" when a Next Header value is unrecognized in a packet. This document extends this to allow intermediate nodes to send this same error for a packet that is  discarded because a node does not recognize a Next Header type.

 This code SHOULD be sent by an intermediate node that discards a packet because it encounters a Next Header type that is unknown in its examination. The ICMP Pointer field is set to the offset of the  unrecognized value within the original packet."

Should an intermediate node *ever* discard a packet because of an unrecognized next header? It might be dangerous to do so. For example, assume that the IETF specifies a new transport layer protocol and that hosts begin to use that protocol. Should intermediate nodes discard those packets because they don't recognized the new Next Header value?

                                                                                                                    Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Wednesday, December 27, 2017 2:09 PM
> To: [email-masked]
> Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-
> 02.txt
> 
> Hello,
> 
> I posted a new version of the ICMP errors for processing limits drafts.
> 
> Changes are mostly to incorporate suggestions in previous feedback (from
> Ron Bonica and others)
> 
> These include:
>   - Defining a destination unreachable code for aggregate header limit
> exceeded (previously this was a parameter problem)
>   - Specifying a reporting priority of the relevant errors
>   - Making pointer point to first octet beyond a byte limit so that sender can
> deduce the limit being enforced
> 
> Thanks,
> Tom
> 
> 
> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: Wed, Dec 27, 2017 at 11:03 AM
> Subject: New Version Notification for draft-herbert-6man-icmp-limits-02.txt
> To: Tom Herbert <[email-masked]>
> 
> 
> 
> A new version of I-D, draft-herbert-6man-icmp-limits-02.txt
> has been successfully submitted by Tom Herbert and posted to the IETF
> repository.
> 
> Name:           draft-herbert-6man-icmp-limits
> Revision:       02
> Title:          ICMPv6 errors for discarding packets due to processing limits
> Document date:  2017-12-27
> Group:          Individual Submission
> Pages:          11
> URL:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dherbert-2D6man-2Dicmp-
> 2Dlimits-2D02.txt&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=pvL6HLo7oV_J0Y6AqpRu2-
> TBQS20pA38UwbRNgsIOqo&s=r1i1GFIYTOgiKfrbn-
> nwx49VlKf44UuxEvRDRWyB_6M&e=
> Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dherbert-2D6man-2Dicmp-
> 2Dlimits_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=pvL6HLo7oV_J0Y6AqpRu2-
> TBQS20pA38UwbRNgsIOqo&s=FGqv2pzxgmxGxhDlCsdf2r6VQIjmXBEzfVCaE
> QqaL4g&e=
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dherbert-2D6man-2Dicmp-2Dlimits-
> 2D02&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=pvL6HLo7oV_J0Y6AqpRu2-
> TBQS20pA38UwbRNgsIOqo&s=w-Q-UAEXySkdcgnae0A1xvpwUel2DrL-
> BK6amDx5uF4&e=
> Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dherbert-2D6man-2Dicmp-
> 2Dlimits-2D02&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=pvL6HLo7oV_J0Y6AqpRu2-
> TBQS20pA38UwbRNgsIOqo&s=XDNQg-OCdD_JWLUOSxvoI68bTMR-
> 2kncebEE5Wrex7M&e=
> Diff:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dherbert-2D6man-2Dicmp-
> 2Dlimits-2D02&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=pvL6HLo7oV_J0Y6AqpRu2-
> TBQS20pA38UwbRNgsIOqo&s=8heB26eCJAwBi7AGuSr4ODGu6Y41nhKpkSOp
> gWvhynw&e=
> 
> Abstract:
>    Network nodes may discard packets if they are unable to process
>    protocol headers of packets due to processing constraints or limits.
>    When such packets are dropped, the sender receives no indication so
>    it cannot take action to address the cause of discarded packets. This
>    document defines ICMP errors that can be sent by a node that discards
>    packets because it is unable to process the protocol headers. A node
>    that receives such an ICMP error may be able to modify what it sends
>    in future packets to avoid subsequent packet discards.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwICAg&c=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=pvL6HLo7oV_J0Y6AqpRu2-
> TBQS20pA38UwbRNgsIOqo&s=aR4Jzl5op10gXIDR-
> YThazwbZqKiQgWjgNeGsg1XocU&e=
> --------------------------------------------------------------------

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 1 Jan 2018 20:36:18 -0400

Hello,

  I totally agree with Ron.., from my point of view an intermediate
device/router/firewall should not discard the packet because of an
unrecognized next header.

Alejandro,

El 1/1/18 a las 7:33 p. m., Ron Bonica escribió:
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Jan 2018 16:24:44 +1300

Hi Ron,
> Should an intermediate node *ever* discard a packet because of an unrecognized next header? It might be dangerous to do so. For example, assume that the IETF specifies a new transport layer protoco…

Such behaviour was made a SHOULD NOT by https://tools.ietf.org/html/rfc7045#section-2.1, and RFC8200 does not overule this.

Since the converse of SHOULD NOT is MAY, it seems reasonable to specify the ICMP behaviour in this case. I assume this would apply to firewalls implementing draft-ietf-opsec-ipv6-eh-filtering, for example. It was because of such firewalls that we put the SHOULD NOT in RFC7045.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Jan 2018 11:16:06 +0100

> Since the converse of SHOULD NOT is MAY, it seems reasonable to specify the ICMP behaviour in this case. I assume this would apply to firewalls implementing draft-ietf-opsec-ipv6-eh-filtering, for…

A) draft-herbert-6man-icmp-limits should have an informational reference
to draft-ietf-opsec-ipv6-eh-filtering.

B) I am somewhat pessimistic about applicability of icmp limits to firewalls:

The EH filtering draft does not specify what ICMP error codes should be
sent back. That is foremost a discussion for opsec WG. As soon as one
would suggest to send anything more than "administratively prohibited"
for different filtering cases from a firewall, you need to have a security
discussion how that additional diagnostics can not be used to refine
an attack. E.g.: deducing type, model and firmware version of the firewall
through the unique fingerprint of limits that can be learned from the ICMP
limit messages == every firewall operator would immediately disable
these ICMP messages.

C) Do we have any IETF text explaining non-firewall examples where
the icmp limits draft would apply ?  The more friendly (non firewall)
devices/functions we can identify/explain the more valuable the draft will
be IMHO.

Providing transport level optimizations and failing to inspect the transport
level because of too many EH clogging up the inspection buffer is a generic
example, but it would be great to have more detailled text about this and
other examples. Especially when one can point to real business important
examples. Port based load balancing in DCs that fails due to EH ??? No
idea what really the most crucial use cases ould be. Would be great to have
them written into the draft (or pointed to via references).

D) I am somewhat concerned that the draft only considers the "drop" case.
Example: router can not perform port/flow based load balancing because
its inspection buffer is too small to see transport header. Instead of
dropping, it could also simply forward without this optimization feature.
But how could it diagnose back to the sender that removal of EH could
improve the experience of the traffic in this case ?

Technically it would IMHO be easily possible to provide this diagnostics
in ICMP, but i would also fear that it would immediately be shot
down with the packet amplification attack vector argument (even though
IMHO that could be easily fixed).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Tue, 2 Jan 2018 15:26:12 +0000

Hi Brian, Tom,

That makes sense. It's a code meant to be sent by a firewall. 

We might want to mention that in the second paragraph of Section 2.2. 

Also, when a firewall blocks a packet today, it may sent and ICMP Destination Unreachable with code equal to "Communication With Destination Administratively Prohibittted" (1). Looking at Section 4.1, I can't tell if that would take priority over Parameter Problem, Unrecognized Next Header.

                                                  Ron

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, January 1, 2018 10:25 PM
> To: Ron Bonica <[email-masked]>; Tom Herbert
> <[email-masked]>; [email-masked]
> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-
> 02.txt
> 
> Hi Ron,
> > "[RFC8200] specifies that a destination host should send an  "unrecognized
> next header type" when a Next Header value is unrecognized in a packet.
> This document extends this to allow intermediate nodes to send this same
> error for a packet that is  discarded because a node does not recognize a
> Next Header type.
> >
> >  This code SHOULD be sent by an intermediate node that discards a packet
> because it encounters a Next Header type that is unknown in its
> examination. The ICMP Pointer field is set to the offset of the  unrecognized
> value within the original packet."
> >
> > Should an intermediate node *ever* discard a packet because of an
> unrecognized next header? It might be dangerous to do so. For example,
> assume that the IETF specifies a new transport layer protocol and that hosts
> begin to use that protocol. Should intermediate nodes discard those packets
> because they don't recognized the new Next Header value?
> 
> Such behaviour was made a SHOULD NOT by
> 3A__tools.ietf.org_html_rfc7045-23section-
> 2D2.1&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> AWF2EfpHcAwrDThKP8&m=mU4Ky4lPJnpyoAtVqDQfOgrNAX8imCHqxwasr8
> Xob1I&s=lM1jvf933_sJplnT6RNDGcGf17aSOFtD2M7qJhaH9CQ&e=, and
> RFC8200 does not overule this.
> 
> Since the converse of SHOULD NOT is MAY, it seems reasonable to specify
> the ICMP behaviour in this case. I assume this would apply to firewalls
> implementing draft-ietf-opsec-ipv6-eh-filtering, for example. It was because
> of such firewalls that we put the SHOULD NOT in RFC7045.
> 
>    Brian
>                                                                                                                     > Ron
> >
> >
> >
> >> Subject: Fwd: New Version Notification for
> >> draft-herbert-6man-icmp-limits- 02.txt
> >>
> >> Hello,
> >>
> >> Changes are mostly to incorporate suggestions in previous feedback
> >> (from Ron Bonica and others)
> >>
> >> These include:
> >>   - Defining a destination unreachable code for aggregate header
> >> limit exceeded (previously this was a parameter problem)
> >>   - Making pointer point to first octet beyond a byte limit so that
> >> sender can deduce the limit being enforced
> >>
> >> Thanks,
> >> Tom
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> 3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> AWF2EfpHcAwrDThKP8&m=mU4Ky4lPJnpyoAtVqDQ
> > fOgrNAX8imCHqxwasr8Xob1I&s=zVVZHeuSt-
> 8x5nRXc5yiNL45CVnWUGGLJ7O_z1W2ZKs
> > &e=

---

From: Ron Bonica <[email-masked]>
Date: Tue, 2 Jan 2018 15:49:23 +0000

> The EH filtering draft does not specify what ICMP error codes should be sent
> back. That is foremost a discussion for opsec WG. As soon as one would
> suggest to send anything more than "administratively prohibited"
> discussion how that additional diagnostics can not be used to refine an
> attack. E.g.: deducing type, model and firmware version of the firewall
> limit messages == every firewall operator would immediately disable these
> ICMP messages.
> 

[RB ] 
In the case of a firewall drop, would it make sense to send an ICMP Destination unreachable with code equal to "Administratively Dropped"?  Tom's draft could define an optional ICMP extension that explains why the packet was dropped.

Each implementation could decide the risk associated with revealing this additional information.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Jan 2018 17:14:36 +0100

Don't ask me, i am all for diagnostics, ask a security experts.
[ The amount of time i've wasted trying to figure out why firewalls dropped
  packets on me and getting it fixed... ]

The authors of rfc4443 explicitly wrote "firewall" as an example of the
"administratively prohibited" code. Alas, rfc7045 does not further mention
or demand that this has to happen if you drop.

Of ourse i would like additional diagnostics such as from Toms draft, but
it is not even a problem of just the implementation.

If i was an (imaginary ;-) vendor building a firewall i would at least implement
an option to enable/disable the extended diagnostics. And a well meaning security expert
in my vendor would create a whitepaper suggesting to disable all diagnostic options
unless the operator was aware of its security implications. And an average operator
would follow those recommendations.

Aka: To actually get this stuff enabled for the mayority of customers,
from firewalls it needs to have 

  a) a standard MUST send (or at least SHOULD send) 
  b) A good discussion how this does not create a security risk outweighing
     its benefits.
  c) Multiple explicit use-case oriented benefit examples

And as i ws suggesting in my prior email: If there ae good use case examples
for non-firewalls, then its a lot easier, because then IMHO we primarily need
c), we could get away with any SHOULD/MAY for a), and we wouldn't have a
big problem with b).

Cheers
    Toerless

P.S.: IMHO firewalls dropping packets should return a code indicating a phone
number to call and a ticket# to refer to ;-)

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Jan 2018 08:18:01 -0800

> In the case of a firewall drop, would it make sense to send an ICMP Destination unreachable with code equal to "Administratively Dropped"?  Tom's draft could define an optional ICMP extension that…
Looking at RFC4443, the description of administratively prohibited is
pretty scant. It seems to indicate a packets is dropped by
administrative policy (blockerd by firewall rule)  as opposed to not
being able to process it.

> Each implementation could decide the risk associated with revealing this additional information.
That would be true for nearly anything implemented. Even without
these errors an attacker could probe a firewall to see what EHs it
allows through, how many it can process, and what other limits it has.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Jan 2018 08:52:07 -0800

> would follow those recommendations.

Hi Toerless,

>   c) Multiple explicit use-case oriented benefit examples
Thank you for this clear synopsis of the requirements!

For a) i don't imagine this could qualify as a MUST or would be
uniformly implemented in the near future as such. SHOULD seems
appropriate.

For b), I agree that such a discussion needs to happen.

For c), I believe that the examples would parallel efforts to use
extension header in the Internet in a meaningful and widely deployed
way. To do that we need to overcome the issues of devices that drop
them. Getting proactive feedback that they are causing drops could be
applied quickly at a host implementing a sort of Happy Eyeballs for
extension headers.

For a firewall, it's conceivable that sending the ICMP errors might be
useful even if just sent it to hosts on the inside network. For
instance, in the case of a client connecting to a content provider
there might only a firewall on the client side network. Also, if a set
of EHs can be processed in the forward direction, then it is probable
that a similar set of EHs will pass through the firewall in the
reverse direction (barring explicit policy that would block them from
the Internet). I have a proposal in mind that would reflect
destination or hbh options when sending back to a source.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Jan 2018 18:42:25 +0100

> uniformly implemented in the near future as such. SHOULD seems

Sure

> applied quickly at a host implementing a sort of Happy Eyeballs for

This is architectural, but i was thinking more of examples that
an operator in an enterprise or the like would understand and say
"hey, yes, i want to have this ICMP option enabled/supported". 

> useful even if just sent it to hosts on the inside network.
> For  instance, in the case of a client connecting to a content provider

That paragraph is good material for b), but IMHO not for c).

For c), think of the minimum complete implementation: sender, firewall, receiver
that could be demoed to operators.

  - Whats a good EH the sender would insert (what vale does it give)
  - Why does firewall drop packet (most likely cases 
    - whitelisting of EHs ? exceeding parse buffer/unable to get to
      whitelisting of transport header/..)
  - ICMP received by sender. Which part of sender drops EH ?
    OS, library, is the app going to be aware of it or not ? 
    (likely may depend on type of EH used),...
  - EH dropped, connection re-established. Great, but value
    of EH not used anymore. So its got to be an "optional" EH,
    for the app.

Which combination of options would in your opinion most easily sell the
idea to operators - so that they will ask vendors (sender, firewall,..) to implement ?

Also note that the explicit examples will be useful to discuss if/what workarounds
we would have to attempt getting EH deployed faster even without this ICMP feature.
For example, happy EH-balls was implemented app-independent in library/OS,
maybe in the absence of the new ICMP messages, one could just rely on
timeouts. But for that one would need to explicitly walk through full fledged
examples.

Also: i was wondering in my first email if you did think of any
non-firewall cases, and if so, what would be the example ? Something
like the load-balancing one i mentioned ?

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Jan 2018 07:43:21 +1300

> or demand that this has to happen if you drop.

Fair comment, but our main objective at the time was to discourage
dropping, not to make it easier to detect. As far as my mail archives go,
nobody raised the ICMP question during the discussion.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Jan 2018 10:44:51 -0800

>   - Whats a good EH the sender would insert (what vale does it give)

IMO, this question is mostly irrelevant. Extension headers are a core
part of IPv6 (RFC8200). We should not have to justify their use to
vendors so that they can approve them. However, vendors should justify
why they are dropping them. These ICMP errors should provide
visibility into that.

That being said, there is an obvious chicken and egg problem here. If
EH is unreliable in the Internet then no one is going to spend effort
to define and use them, but if no one is trying to define an use them
then there's no motivation to make them work on the Internet. How do
we break this cycle?

>       whitelisting of transport header/..)

That's a good question. For HBH, I suspect the requirement that they
must be processed by every node in the path is motivation to
unilaterally drop them. For, destination options I suspect it's more
of a conservative position to drop something that the device doesn't
understand and hence assumes it is a threat.

>     OS, library, is the app going to be aware of it or not ?

That is obviously implementation dependent. In the case of TCP, this
can be implemented in the stack without interaction with the
application. For applications that handle transport protocol in
userspace (e.g. QUIC) this would probably be done in a library.

>     of EH not used anymore. So its got to be an "optional" EH,
Yes, it's similar to backoff to IPv4 if IPv6 is not working, however
in this case the connection should not have to be reestablished, just
stop using EH if they're not working.

> idea to operators - so that they will ask vendors (sender, firewall,..) to implement ?
Again, we shouldn't have to sell vendors on this. RFC8200 is clear
that "extension headers (except for the Hop-by-Hop Options header) are
not processed, inserted, or deleted by any node along a packet's
deliver path, until the packet reaches the node".  So, for instance,
if we create a new destination option it shouldn't be the case that
devices arbitrarily drop the packet because they don't know the
option-- that would not comply with RFC8200. If they have do drop EH
for some specific reason, a white-listed option or processing limits
exceeded, then it is reasonable that they at least provide visibility
into their action so that end hosts can adjust and not be left in the
dark.

> timeouts. But for that one would need to explicitly walk through full fledged
Sure, but waiting for timeouts take a lot more time. Also, happy
eyeballs schemes won't scale if there are multiple dimensions that
need do be probed (different options, IPv6 vs. IPv4, etc.).

> like the load-balancing one i mentioned ?
I don't think there's any reason to distinguish the non-firewall
cases. The draft should be applicable to any device (both hosts and
intermediate nodes) that drops packets because processing limits are
exceeded. For slow path relegation, I think that these errors could be
meaningfully used to motivate a sender to backoff sending, but unlike
dropping a packet I don't see any way to quantify what the "slow path"
in a network device means to a sender.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Jan 2018 10:51:34 -0800

On Jan 2, 2018 10:44 AM, "Tom Herbert" <[email-masked]> wrote:

for some specific reason, a white-listed

I meant black-listed. White-lists prevent us from deploying anything new on
the Internet.

option or processing limits
exceeded, then it is reasonable that they at least provide visibility
into their action so that end hosts can adjust and not be left in the
dark.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Jan 2018 08:40:33 +1300

>> On Tue, Jan 02, 2018 at 08:52:07AM -0800, Tom Herbert wrote:
...>>   - Why does firewall drop packet (most likely cases
> unilaterally drop them. 

That requirement was downgraded to a SHOULD a while ago:
https://tools.ietf.org/html/rfc7045#section-2.2
and this is recognised by
https://tools.ietf.org/html/rfc8200#section-4.8

In other words it is now consistent with the standards to simply
ignore HBH.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Jan 2018 12:02:14 -0800

> In other words it is now consistent with the standards to simply
Brian,

That is a good step forward, but we'll still need to deal with legacy
implementations for a while some of which don't drop but relegate HBH
to a slow path that could also render them fairly useless. As it
stands today, there's a better chance of getting destination options
through the Internet, so if I were creating a new option I would try
to define it as both a HBH and destination option and use the one that
works best for some destination.

Tom

---

From: Ole Troan <[email-masked]>
Date: Thu, 4 Jan 2018 13:24:47 +0100

While I am somewhat supportive of more diagnostics, I do have questions on the practical applicability of this though.

Given these snippets from the draft:

   A  source host that receives an ICMP error can modify the headers used
   in subsequent packets to try to avoid further occurrences of packets
   being discarded or relegated to a slow path.

   A host system SHOULD take action if it is automatically
   inserting extension headers into packets unbeknownst to the
   application. The host system SHOULD either stop using extension
   headers or modify its used of extension headers for subsequent
   packets sent to the destination indicated in the packet of the
   ICMP error.

Are applications expected to dynamically probe? My impression was that applications barely deal with ICMP messages today, do we have concrete examples of applications capable of this?
If they could function even without an extension header, why would they bother with the extension header in the first place?
It's hard to figure out what the "SHOULD" should be...

In short, I'm unsure of the practical application for this.

Best regards,
Ole

> On 27 Dec 2017, at 20:08, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> has been successfully submitted by Tom Herbert and posted to the
> IETF repository.
> 
> https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/
> Htmlized:       https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-herbert-6man-icmp-limits-02
> 
> Abstract:

---

From: Tom Herbert <[email-masked]>
Date: Thu, 4 Jan 2018 08:23:35 -0800

>    packets sent to the destination indicated in the packet of the
Ole,

> Are applications expected to dynamically probe?

I would say yes if the plan is to ever use extension headers on the
Internet. Until there is universal support in all paths, an
application will need to deal with potential drops. An application
can't blindly enable extension headers without a fallback as long as
there is a significant probability they will cause drops.

> My impression was that applications barely deal with ICMP messages today, do we have concrete examples of applications capable of this?

Packet to big is handled for PMTU discovery by stacks and
applications. Given that ICMP is notorius for being unreliable it
can't be the only mechanism, transport layer timeouts are relevant to
this sort of probing.

> If they could function even without an extension header, why would they bother with the extension header in the first place?

For a similar reason that if an application already works over IPv4
why bother making it work over IPv6? :-)  I think the answer is that
without use of extension headers the application is functional but is
operating in a degraded mode. It doesn't get the services offered by
use of extension headers. IMO, the compelling services are those that
would interact with the network such as segment routing or use EH for
signaling QoS or application characterisitics to the network.

> In short, I'm unsure of the practical application for this.
I think the root purpose here is to help make use of extension headers
practical.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Wed, 10 Jan 2018 13:03:18 -0800

Hi,

Reading the discussion on this draft, I wonder if we need to distinguish more clearly the difference between the handling of Destination EH (and it's Options) vs. other Extension Headers.  Note, I am purposely ignoring the Hop-by-Hop extension header as I think it is mostly useless on the open Internet.

It seems to me that having middle boxes look at or ignore Destination EH is quite different from some new random extension header.  Destination EH options have a common format to make parsing possible, where all bets are off for a newly defined EH even if it follows Section 4.8 of RFC8200 (i.e., RFC6564).

If we are discussing how to handle extension headers, I think it’s important to distinguish the different types, especially the Destination Extension header.

Comments?

Bob

> On Jan 4, 2018, at 8:23 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 Jan 2018 13:31:39 -0800

> If we are discussing how to handle extension headers, I think it’s important to distinguish the different types, especially the Destination Extension header.
Hi Bob,

I 'm not sure what you have in mind.

Code 6 "Too many options in extension header" in the draft is already
only applicable based on parsing Destination or HBH EH.

Do you think there needs to be more codes about why a node might drop
a packet with destinaton options? I wouldn't believe it's reasonable
for an intermediate node to drop a packet based on an option type
being ecountered so that should not need ICMP errors (i.e.
intermediate nodes don't act on action bits in destination options).

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 Jan 2018 13:35:13 -0800

> for an intermediate node to drop a packet based on an option type

unknown option type that is

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 11 Jan 2018 12:57:42 +0100

> Reading the discussion on this draft, I wonder if we need to distinguish more clearly the difference between the handling of Destination EH (and it's Options) vs. other Extension Headers.  Note, I…

Why ?

Most IPv6 networking paths will go through two controlled network path segments on the end where hop-by-hop extension headers could be quite useful and the open Internet path segment in the middle should be able to transparently pass on that extension header. And if some well-meaning "open internet" DPI box trying to get to transport headers to do something with them fails to do so because of extension headers (whichever ones) push the transport header beyond its parse buffer, then it would improve the ability of end-systems to deal with this case if there was the proposed ICMPv6 signaling. And that one could be implemented in the DPI box as a software fix as opposed to the parse buffer increase which would typically require a HW swap.

Of course, i would still love to see some example use case scenarios documented (whatever extension header), especialyl to see:

  - how long could todays extension headers really become (aka: which parse buffer depth would be save in all current possible cases
  - is there today really any example of "intelligent" reaction of endpoints - extension headers that offer benefit when inserted, but where the application (or node) can still perform well enough if it removes the extension header.

Yes, i could probably figure out the answer to these questions myself if i would read through a lot more IPv6 RFCs, but i would like for this draft to support lazy readers  like myself who are not prepared to do that.

> If we are discussing how to handle extension headers, I think it???s important to distinguish the different types, especially the Destination Extension header.

Can you come up with an example of two different type of extension headers and how distinguishing them by ype in the draft would be useful ?

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jan 2018 08:37:54 +1300

Hi Toerless,
> Most IPv6 networking paths will go through two controlled network path segments on the end where hop-by-hop extension headers could be quite useful and the open Internet path segment in the middle…

The Hop-by-Hop header is pretty much unreliable on the open Internet because it is at significant
risk of being either kicked to the slow path or dropped or ignored. That's why it now carries
a couple of health warnings:
"However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour." [RFC7045]
 
"...it is now expected that nodes
   along a packet's delivery path only examine and process the
   Hop-by-Hop Options header if explicitly configured to do so." [RFC8200]

>   - how long could todays extension headers really become (aka: which parse buffer depth would be save in all current possible cases

The worst case is shim6, where technically the answer is 1240 bytes, although 68 bytes is
more realistic. Not that anybody uses shim6.

>   - is there today really any example of "intelligent" reaction of endpoints - extension headers that offer benefit when inserted, but where the application (or node) can still perform well enough…

See http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
I think the answer is again shim6; a shim6 host will revert to normal processing if it
gets no shim6 extension header in response.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 Jan 2018 12:19:19 -0800

>    Hop-by-Hop Options header if explicitly configured to do so." [RFC8200]
If I'm reading it correctly, the data in RFC7872 put the drop rates on
the Internet at about 11% for destination options and 40% for HBH.
Hopefully, the allowance in RC8200 will reduce the drops of HBH but
that will take some time . Another concern that HBH would raise is
that even if packets aren't being dropped they might be relegated to
slow path which could be just as bad to end user as a drops (maybe
even worse!). For the foreseeable future at least, it seems that
destination options might be viable on the open Internet, whereas HBH
options aren't. I think we can work with a 10% drop rate for
destination options, but we'll always need a fallback until the drops
go to zero.

>>   - how long could todays extension headers really become (aka: which parse buffer depth would be save in all current possible cases
By the spec they can fill up an MTU sized packet. This allows hundreds
of options in a single packet which makes for a good denial of service
attack. To mitigate the attack, we recently implemented limits Linux
on how many non-padding options are allowable (default limit is eight
for both DO and HBH).

> gets no shim6 extension header in response.
Also, I just posted a new draft on "Firewall and Service Tickets"
https://tools.ietf.org/html/draft-herbert-fast-00. The basic idea is
that end hosts request packet services (low latency, video, netwtok
slice selection, etc.) that are encoded in EH options. The fallback if
EH doesn't work is to not get any special services applied.

Tom