Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-01.txt

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 15:22:10 -0700

Hello,

I added a section on host's response to the ICMP errors in this version.

Also, I checked how Linux would deal with these errors. Currently, any
Parameter Problem ICMP errors are assumed to be hard errors. There are
reported to the application and in the case of TCP the connection is
terminated. We can modify this behavior to take more appropriate
action for the codes described in the draft.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Wed, May 10, 2017 at 3:17 PM
Subject: New Version Notification for draft-herbert-6man-icmp-limits-01.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-6man-icmp-limits-01.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-6man-icmp-limits
Revision:       01
Title:          ICMPv6 errors for discarding packets due to processing limits
Document date:  2017-05-10
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-01.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/
Htmlized:       https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-herbert-6man-icmp-limits-01

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
   sender 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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 May 2017 14:37:03 +0000

Hi Tom,

Thanks for doing this work. The following are a few obsessive/compulsive comments:

1) When a packet is dropped because an extension header is too large (Section 3.2), it would be great  if the ICMP message could indicate the maximum size for the offending extension header. You could use the pointer to do this. Rather than setting the pointer to reference the first byte of the offending header, set the pointer to reference the first offending byte of the offending header.
2) Same comment for Sections 3.3 and 3.4
3) I'm not sure that I get the difference between Extension Header Chain Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you saying that there is a case where 3.5 will be true and 3.3 will be false?
4) What happens when a packet is dropped for more than one of the conditions listed in 3.1 - 3.5? What is the priority of reporting?

                                                                                         Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Wednesday, May 10, 2017 6:22 PM
> To: [email-masked]
> Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-
> 01.txt
> 
> Hello,
> 
> terminated. We can modify this behavior to take more appropriate action for
> the codes described in the draft.
> 
> Thanks,
> Tom
> 
> 
> 
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 May 2017 09:10:48 -0700

> Thanks for doing this work. The following are a few obsessive/compulsive comments:
Hi Ron,

> 1) When a packet is dropped because an extension header is too large (Section 3.2), it would be great  if the ICMP message could indicate the maximum size for the offending extension header. You co…

Yes, that is better.

> 3) I'm not sure that I get the difference between Extension Header Chain Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you saying that there is a case where 3.5 will be true and 3.…

Headers too long could be caused by and reference encapsulation
headers as the culprit, it's not specific to extension headers.

> 4) What happens when a packet is dropped for more than one of the conditions listed in 3.1 - 3.5? What is the priority of reporting?

Priority for reporting should be specified. May order is (most
specific to least specific problem):

- Real error (existing codes)
- Too many options in EH
- Extension header too big
- Extension header chain too long
- Headers too long

Tom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 May 2017 17:53:26 +0000

Tom,

I may be parsing your response incorrectly.. Can you provide an example where encapsulations elicit a Headers Too Long error code?

                                                                                                      Ron

> > 3) I'm not sure that I get the difference between Extension Header Chain
> Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you saying
> that there is a case where 3.5 will be true and 3.3 will be false?
> 
> Headers too long could be caused by and reference encapsulation headers as
> the culprit, it's not specific to extension headers.
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 May 2017 14:27:46 -0700

> I may be parsing your response incorrectly.. Can you provide an example where encapsulations elicit a Headers Too Long error code?

It would be the case because of encapsulation a device is unable to
parse the headers it wants (typically would be down to transport
headers). For instance in Geneve, the maximum header length is 260
bytes. Adding UDP outer header and using it for IPv6/IPv6
encapsulation gets the headers before the inner transport header up to
348 bytes. That in itself may exceed a parsing buffer. A few more
extension headers, SFC, or nested encapsulation could push the headers
over 512 bytes that would probably exceed the parsing buffer sizes of
many devices. So The Headers Too Long could be sent in this case.
Implementing a fallback might be hard since there may be multiple
sources of the headers, but at least this might give some visibility
to packet drops happening.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Tue, 16 May 2017 16:52:13 +0000

Tom,

I was confused before reading your response. Now I a profoundly confused :-/

In your example, I think that the header stack looks like this:

A) payload
	3) data
	2) TCP header (8 bytes)
	1) IPv6 header (40 bytes)
B) Geneve
	3) Geneve header (260 bytes)
	2) UDP Header (8 bytes)
	1) IPv6 Header (40 bytes)

It doesn't contain any IPv6 extension headers at all. A transit router, acting  as a middlebox, needs to see the TCP header, but can't because the TCP header is 340 bytes into the packet. So, we send an ICMPv6 Parameter Problem. 

Do I have that much right?

                                                                                      Ron

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, May 15, 2017 5:28 PM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]
> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-
> 01.txt
> 
> > I may be parsing your response incorrectly.. Can you provide an example
> where encapsulations elicit a Headers Too Long error code?
> 
> It would be the case because of encapsulation a device is unable to parse the
> headers it wants (typically would be down to transport headers). For
> instance in Geneve, the maximum header length is 260 bytes. Adding UDP
> outer header and using it for IPv6/IPv6 encapsulation gets the headers
> before the inner transport header up to
> 348 bytes. That in itself may exceed a parsing buffer. A few more extension
> headers, SFC, or nested encapsulation could push the headers over 512
> bytes that would probably exceed the parsing buffer sizes of many devices.
> So The Headers Too Long could be sent in this case.
> Implementing a fallback might be hard since there may be multiple sources
> of the headers, but at least this might give some visibility to packet drops
> happening.
> 
> Tom
> 
> >
> >
> > Ron
> >
> >>
> >> Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you
> >> saying that there is a case where 3.5 will be true and 3.3 will be false?
> >>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 16 May 2017 14:04:04 -0700

> Do I have that much right?
Yes, that is correct. Looking at the definition of Parameter Problem
in RFC1122 it seems the use here is okay even though the problem might
not specifically be about  IP layer.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Thu, 18 May 2017 01:03:40 +0000

Tom,

The ICMP Parameter Problem message normally indicates that there is a problem with an IP Parameter. In the example below, you use it to indicate that a middle box has a problem with the IP payload. This seems to be overloading the Parameter Problem message.

                                                                                      Ron

> Sent: Tuesday, May 16, 2017 5:04 PM
> > It doesn't contain any IPv6 extension headers at all. A transit router, acting
> as a middlebox, needs to see the TCP header, but can't because the TCP
> header is 340 bytes into the packet. So, we send an ICMPv6 Parameter
> Problem.
> >
> Yes, that is correct. Looking at the definition of Parameter Problem in
> RFC1122 it seems the use here is okay even though the problem might not
> specifically be about  IP layer.
> 
> Tom
> 
> >
> > Ron
> >
> >
> >> Subject: Re: New Version Notification for
> >> draft-herbert-6man-icmp-limits- 01.txt
> >>
> >> extension headers, SFC, or nested encapsulation could push the
> >> headers over 512 bytes that would probably exceed the parsing buffer
> sizes of many devices.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 May 2017 13:50:47 -0700

Hi Ron,

Would Destination Unreachable message be appropriate then?

Tom

---

From: Ron Bonica <[email-masked]>
Date: Sat, 20 May 2017 15:49:00 +0000

Hi Tom,

Destination Unreachable isn't appropriate because the destination *is* reachable. The problem is that the header is too long.

It seems like we are identifying an new constraint, the Path Maximum Header Length (PMHL). In some respects, PMHL is similar to PMTU. When PMTU is violated, we send an ICMP PTB to the source IP stack. The source IP modifies its estimate of the PMTU, informs upper layers (if appropriate) and fragments subsequent packets (if appropriate).

What should happen when PMHL is violated? Does the source IP stack need to be informed? If so, what will the source IP stack do with the information? Or is really an upper layer application that needs to be informed?

                                                                                    Ron

> Sent: Thursday, May 18, 2017 4:51 PM
> > The ICMP Parameter Problem message normally indicates that there is a
> problem with an IP Parameter. In the example below, you use it to indicate
> that a middle box has a problem with the IP payload. This seems to be
> overloading the Parameter Problem message.
> >
> Hi Ron,
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 May 2017 14:29:05 +1000

> Destination Unreachable isn't appropriate because the destination *is* reachable. The problem is that the header is too long.

It seems a DU is appropriate, going by what RFC4443 says, because the
cause of the failure isn't congestion:

"A Destination Unreachable message SHOULD be generated by a router, or
   by the IPv6 layer in the originating node, in response to a packet
   that cannot be delivered to its destination address for reasons other
   than congestion.  (An ICMPv6 message MUST NOT be generated if a
   packet is dropped due to congestion.)"

(I looked it up because this discussion made me curious if a DA -
Admin prohibited was making a positive confirmation of the
destination's existence, and the prohibition was on being able to
reach it. It seems not, which is better for security.)

Regards,
Mark.

> IETF IPv6 working group mailing list
> [email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Mon, 22 May 2017 14:09:56 +0000

Mark,

Strictly speaking, Destination Unreachable is appropriate whenever a packet is discarded for any reason other than congestion. But according to that reasoning, you don't need an ICMP Packet Too Big message. The PTB error could be reported  by Destination Unreachable message with a PTB error code.

In reality, we need the ICMP PTB message because of its special status. That is, people know that they MUST NOT filter ICMP PTB's because filtering may cause black-holing. I am thinking that Header Too Long (HTL)  is akin to PTB. If HTL information hitchhikes on an existing ICMP message, that message should probably be PTB.

But then again, a new ICMP message may be required.

                                                                   Ron

> From: Mark Smith [mailto:[email-masked]]
> Sent: Sunday, May 21, 2017 12:29 AM
> Cc: Tom Herbert <[email-masked]>; [email-masked]
> > Destination Unreachable isn't appropriate because the destination *is*
> reachable. The problem is that the header is too long.
> 
> It seems a DU is appropriate, going by what RFC4443 says, because the cause
> of the failure isn't congestion:
> 
> 
> (I looked it up because this discussion made me curious if a DA - Admin
> prohibited was making a positive confirmation of the destination's existence,
> and the prohibition was on being able to reach it. It seems not, which is
> better for security.)
> 
> Regards,
> Mark.
> 
> 
> 
> >
> > It seems like we are identifying an new constraint, the Path Maximum
> Header Length (PMHL). In some respects, PMHL is similar to PMTU. When
> PMTU is violated, we send an ICMP PTB to the source IP stack. The source IP
> modifies its estimate of the PMTU, informs upper layers (if appropriate) and
> fragments subsequent packets (if appropriate).
> >
> > What should happen when PMHL is violated? Does the source IP stack
> need to be informed? If so, what will the source IP stack do with the
> information? Or is really an upper layer application that needs to be
> informed?
> >
> >
> > Ron
> >
> >
> >
> >
> >> problem with an IP Parameter. In the example below, you use it to
> >> indicate that a middle box has a problem with the IP payload. This
> >> seems to be overloading the Parameter Problem message.
> >> >
> >> Hi Ron,
> >>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 May 2017 08:44:02 -0700

> Strictly speaking, Destination Unreachable is appropriate whenever a packet is discarded for any reason other than congestion. But according to that reasoning, you don't need an ICMP Packet Too Big…
To be completely pedantic then, the RFC4443 description of destination
unreachable isn't entirely correct. PTB, Parameter problem, and time
exceeded are used for discarded packets as opposed to destination
unreachable and are not congestion.

> In reality, we need the ICMP PTB message because of its special status. That is, people know that they MUST NOT filter ICMP PTB's because filtering may cause black-holing. I am thinking that Header…
I don't think HTL should qualify for that special status. The
difference between PTB and HTL is the response the sending host(s)
take. For PTB the response is deterministic, the sending application
should lower its PMTU. But handling of HTL is not deterministic, it
may or may not be feasible to reduce headers to fit. The response to
HTL might be more on the administrative side like other destination
unreachable errors.

> But then again, a new ICMP message may be required.
Isn't it more likely a new ICMP type would be filtered more than PTB
or destination unreachable?

Tom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 22 May 2017 18:47:49 +0000

Hi Tom,

This raises the salient question. When the source IP stack receives a message informing it that HTL has been exceeded, what should it do?

When the source IP stack receives an ICMP PTB message, the required action is well-understood. It should:

- update its estimate of the PMTU associated with the destination of the original packet
- inform a higher layer protocol if appropriate
- refrain from sending messages that exceed the PMTU in the future

When the source IP stack receives a message informing it of a HTL violation, what should it do? 

                                                                    Ron

> I don't think HTL should qualify for that special status. The difference
> between PTB and HTL is the response the sending host(s) take. For PTB the
> response is deterministic, the sending application should lower its PMTU. But
> handling of HTL is not deterministic, it may or may not be feasible to reduce
> headers to fit. The response to HTL might be more on the administrative side
> like other destination unreachable errors.
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 May 2017 14:19:44 -0700

> When the source IP stack receives a message informing it of a HTL violation, what should it do?
I think the response would be similar to that described in section 4.
The error should at least be logged and the higher layer protocol
informed. If possible, the headers can be reduced but there is no
deterministic way to do that. It's possible that it was an
encapsulation header that put things over the edge, so if the ICMP
error is received by the encapsulator it's possible that those headers
could be trimmed (for instance be withhold some unnecessary options in
an extensible encapsulation).

Tom

---

From: Ron Bonica <[email-masked]>
Date: Tue, 23 May 2017 19:26:46 +0000

Hi Tom,

I think that we are converging. The Parameter Problem message is appropriate for the following error codes:

      Code 
         1 - Unrecognized Next Header type encountered
         4 - Extension header too big
         5 - Extension header chain too long
         6 - Too many options in extension header

For error codes 4, 5, and 6, the pointer should reference the first *invalid* byte. This will allow the source node to infer:
 
      Code
         4 - The maximum extension header length
         5 - The maximum extension header chain length
         6 - The maximum number of options in the extension header

Even when none of the above-mentioned errors occur, a middle box may discard a packet because the Total Header Length (THL) has been exceeded. The total header length is the sum of the IPv6 header length, the IPv6 extension header chain length and the encapsulation header.

In order for the middle-box to inform the source of a THL violation, it can send either:

- a new ICMP message
- a Destination Unreachable Message

I have no preference. 

However, if you choose, the Destination Unreachable message, you will want to inform the source of the Maximum Header Length. RFC 4884 provides a mechanism that you can use to piggyback this information on the Destination unreachable.

                                                                                  Ron

> Sent: Monday, May 22, 2017 5:20 PM
> Cc: Mark Smith <[email-masked]>; [email-masked]