Subject: Conflicting requirements for sending ICMPv6 and EH scan?

From: Tom Herbert <[email-masked]>
Date: Fri, 24 May 2019 13:58:08 -0700

Hello,

I am updating the references in Linux stack from RFC2460 to RFC8200. I
came across the ipv6_skip_exthdr function which contains a long, and
somewhat apologetic, comment that this function is purposely walking
over all the IPv6 extension headers for the purpose of locating the
transport layer protocol and hence violates RFC2460 (RFC8200):

"Therefore, extension headers must be processed strictly in the order
they appear in the packet; a receiver must not, for example, scan
through a packet looking for a particular kind of extension header and
process that header prior to processing all preceding ones."

The need for this function arises from the requirement of RFC4443:

"(e) An ICMPv6 error message MUST NOT be originated as a result of
       receiving the following:

       (e.1) An ICMPv6 error message."

So, for instance, if we are sending an ICMP error because of a problem
with an extension header, we need to walk (process) the  other
extension headers to determine if the transport is ICMPv6 and if it is
then not send the error.

The comment is over fourteen years old! I would like to resolve
somehow as not being a violation of standard. Any ideas how to do
that?

Thanks,
Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 May 2019 08:57:18 +0200 (CEST)

> somehow as not being a violation of standard. Any ideas how to do

Is this ipv6_skip_exthdr only used as a sanity check when having decided 
to send an ICMP6v6 error message, or is it used in other cases as well?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Sat, 25 May 2019 15:47:36 -0700

> to send an ICMP6v6 error message, or is it used in other cases as well?
Mikael,

Good question! Yes, it seems to be called in a few cases. We also skip
over extension headers when trying to determine the flow of packet
(for firewall or hash for ECMP, etc.). The commonality amongst all
these cases seems to be that they are doing passive DPI with the
purpose of extacting higher protocol layer information about a packet
to make decisions or to fulfil requirements when processing lowering
layers (as in the case of the ICMPv6). So I think it might be
reasonable to say that these conform with the spirit of RFC8200
requirements since this is only parsing headers beyong the current
header being processed, not actually performing the specified
processing of deeper protocol headers out of order.

The also implies another subtle issue. ESP might be used in transport
mode with ICMP, so it would is impossible to determine in that case
whether an ESP packet contains an ICMP error. That's probably a
pathological issue.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sat, 25 May 2019 18:24:06 -0400

Hello, Tom,

> process that header prior to processing all preceding ones."

IN the context of your message, Linux would be okay in this respect (but
se below), since the spirit is mostly that when you process a packet,
you act on each EH in the order they were included in the packet. IN
this sense, the code you are referring to is peeking on the packet (or
simply "parsing the EH chain"), as opposed to "processing the EH chain"
(similar as what a FW would do when meaning to enforce filters on
layer-4 values).

>        (e.1) An ICMPv6 error message."

At least theory, a node might not be able to comply with this
requirement. As noted in
https://www.ietf.org/archive/id/draft-gont-6man-rfc6564bis-01.txt , it
is not really possible to parse past unknown EHs.

> extension headers to determine if the transport is ICMPv6 and if it is

In this context, I wouldn't call this "process", but "peeking" at the
packet -- or just parsing it.

One would assume that ICMPv6 errors will never employ newly-specifed
EHs, and hence you'd be able to parse the EH chain. That's what I expect
in the real world.

Specs-wise, and strictly (theoretically) speaking, an ICMPv6 error might
use unknown EHs, and hence you might be unable to tell what's the uper
layer protocol.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ole Troan <[email-masked]>
Date: Sun, 26 May 2019 13:12:24 +0200

Hi Tom,

The rfc4443 text you are quoting is from section 2.4. That deals with processing rules for ICMP messages. That is, you already know you have received an ICMP at that point. 

If you are looking at the corner case where someone sends you an ICMP message with an unparsable extension header chain, then you have to treat that as any other packet with unknown headers. 

Cheers 
Ole

> On 24 May 2019, at 22:58, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 May 2019 14:54:11 -0700

On Sun, May 26, 2019, 4:12 AM Ole Troan <[email-masked]> wrote:

> Hi Tom,
>
> The rfc4443 text you are quoting is from section 2.4. That deals with
> processing rules for ICMP messages. That is, you already know you have
> received an ICMP at that point.
>
> If you are looking at the corner case where someone sends you an ICMP
> message with an unparsable extension header chain, then you have to treat
> that as any other packet with unknown headers.
>

Ole, here is an example scenario:

A host receives a packet with a destination option whose type is
unrecognized by the host. The high order bits of the option type indicate
that an ICMP error should be sent in response to receiving an unknown
option. But, per the text quoted from RFC4443, we are not permitted to send
the ICMP error if the received packet was itself an ICMP error packet. At
this point, we're only processing the destination options, so we don't know
yet whether or not the received packet is ICMP-- the only way to determine
that is to parse the packet beyond the destination options EH to find the
transport protocol.

Tom

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 12:23:31 +0200

Tom,

> A host receives a packet with a destination option whose type is unrecognized by the host. The high order bits of the option type indicate that an ICMP error should be sent in response to receiving an unknown option. But, per the text quoted from RFC4443, we are not permitted to send the ICMP error if the received packet was itself an ICMP error packet. At this point, we're only processing the destination options, so we don't know yet whether or not the received packet is ICMP-- the only way to determine that is to parse the packet beyond the destination options EH to find the transport protocol.

But in the general case you cannot. And probably shouldn't either.
In this case the stack cannot know that it has received an ICMP message and the provisions in RFC4443 do not apply.

Is there any case where an ICMP error message can include extension headers before the ICMP header?

If we allow that, you could indeed imagine a (very constructed) case, where host A sends host B an unparsable header chain ICMP, and host B responds with a different unparsable header chain ICMP.

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 09:26:50 -0700

> But in the general case you cannot. And probably shouldn't either.

Ole,

Unless there's an unknown EH or the ICMP message is in ESP, this
algorithm should work pretty well. The only downside really is the
potential for a false negative where we couldn't determine the ICMP
message and send an error contrary to RFC4443. Conceptually, we could
eliminate the false negatives by parsing to find if the packet
contains a recognizable end transport protocol (TCP, UDP, SCTP, etc.)
and if we can't find one withhold the ICMP error. That would be closer
to conformance with RF4443 at the cost of more implementation
complexity and now false positives where we could have sent the ICMP
error but didn't.

> In this case the stack cannot know that it has received an ICMP message and the provisions in RFC4443 do not apply.

Strictly reading RFC4443, if we don't know rather the packet in error
is ICMP we can't send an ICMP error. So if we can't parse beyond an
extension header to determine if the packet is ICMP, we can never send
an ICMP error because of an extension header problem!

> Is there any case where an ICMP error message can include extension headers before the ICMP header?

Sure. There's no restrictions for using extension header headers with
ICMP. For example, when a host sends an ICMP error to some peer the
destination address is routed and the route lookup for that
destination may provide a routing header, hop-by-hop options, etc. We
don't typically do special routing for ICMP.

> If we allow that, you could indeed imagine a (very constructed) case, where host A sends host B an unparsable header chain ICMP, and host B responds with a different unparsable header chain ICMP.

Yep, that is a problem and presumably why RFC4443 mandates to not send
ICMP in response to ICMP errors.

Tom

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 19:11:20 +0200

Tom,

> complexity and now false positives where we could have sent the ICMP

I do not believe RFC4443 covers this case at all.
In my reading there is nothing indicating that an implementation is expected to do what Linux does.

> an ICMP error because of an extension header problem!

No. This case just isn't covered in RFC4443.
Presumably because no-one thought it made any sense to wrap an ICMP error in EH unknown to the source.

> ICMP in response to ICMP errors.

Sure, but I don't think the text in RFC4443 requires you to parse deeper into the packet than an extension header with error.
Personally I think that's the wrong behaviour.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 10:53:15 -0700

> Personally I think that's the wrong behaviour.
Okay, but then what do you think is the right behavior in these circumstances?

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 20:57:33 +0200

> On 28 May 2019, at 19:53, Tom Herbert <[email-masked]> wrote:
> 

If in host processing (forus / receive) of a packet you find a problem in a field in a header, you SHOULD send an ICMPv6 parameter problem message back to the packet's source.
Regardless of what header could theoretically follow the erronous one. Continuing parsing at that point seems flawed with risk.

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 May 2019 15:26:57 -0400

(Trimmed.)
If you don't check for ICMP in the received message, couldn't one easily 
get two misbehaving boxes (each trying to use an option the other 
doesn't understand) bouncing ICMPs back and forth?  Preventing that is 
the reason for the rule.

Yours,
Joel

PS: I am not worried about an encrypted or otherwise re-encapsulated 
ICMP.  Choosing to do that is asking to hurt yourself.  And the 
resulting header is the header for the ICMP anyway.  So it is really a 
different case.

On 5/28/19 2:57 PM, Ole Troan wrote:
...

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 12:33:24 -0700

> doesn't understand) bouncing ICMPs back and forth?  Preventing that is
Agreed, that seems to be the potential problem RFC4443 is considering.
I'm also concerned that this could somehow be contorted into an
interesting denial of service attack.

>From a risk management and robustness perspective, I'd say it's better
to not send an ICMP error when we could have, rather than sending a
ICMP error when we should not have.

Tom

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 22:26:40 +0200

Joel,

> (Trimmed.)
> If you don't check for ICMP in the received message, couldn't one easily get two misbehaving boxes (each trying to use an option the other doesn't understand) bouncing ICMPs back and forth?  Preventing that is the reason for the rule.

Right.
If host A includes in it's ICMP error messages an unknown to host B EH _ and_ host B includes an unknown to host A EH in it's ICMP error messages, you would get a loop.
That I don't think we can fix, apart from stating though shalt not do that.

Now, for the case where host A includes in it's ICMP error message an known EH, but with a problematic option inside, and host B would do the same, then Tom's "skip to the end if I can" approach would work.
And thinking some more about it, I think that behaviour is the correct one. And as I think was pointed out earlier, you are not "processing headers" any longer, you are just peaking at the upper layer protocol type.

Cheers,
Ole

> 
> Yours,
> Joel
> 
> PS: I am not worried about an encrypted or otherwise re-encapsulated ICMP.  Choosing to do that is asking to hurt yourself.  And the resulting header is the header for the ICMP anyway.  So it is really a different case.
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 13:58:10 -0700

Ole,

Yes, I think the approach is reasonable (and we've been doing it for
fourteen years anyway!).

Assuming we do continue to perform the deep parse, then what should be
done if we can't conclusively determine whether or not the packet
contains an ICMP error (for instance we hit something like an
unrecognized next header or ESP)? Right now the ICMP error is sent
anyway, but strict adherence to RFC4443 might imply we shoudn't send.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 May 2019 19:21:31 -0400

> That I don't think we can fix, apart from stating though shalt not do that.

We can: draft-gont-6man-rfc6564bis. ;-)

The biggest problem is that with the current situation we have
essentially killed new transport protocols or extension headers.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 May 2019 11:58:48 +1000

> essentially killed new transport protocols or extension headers.

On the public Internet perhaps.

Inside individual networks less so, and if the devices their operators
have deployed block them, the operator is or should be in a position
to fix that (or demand their device vendor give them a knob to fix
it).

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2019 09:35:30 +0200

Tom,

> Yes, I think the approach is reasonable (and we've been doing it for

Agree, and at the same time I do not agree it is mandated by RFC.
(and we can of course discuss if it should have been. ;-))

> anyway, but strict adherence to RFC4443 might imply we shoudn't send.

That's equivalent to my first example above.
You encounter a parameter problem in a header chain that cannot be walked to the end, you should send the ICMP.
Of course at that point it would be unwise to likely known or likely unknown EHs before the ICMP header, in the ICMP error response...

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 03:47:44 -0400

> Of course at that point it would be unwise to likely known or likely unknown EHs before the ICMP header, in the ICMP error response...

Don't worry... they will be filtered by the network, anyway... ;-))

Cheers,

---

From: Ron Bonica <[email-masked]>
Date: Wed, 29 May 2019 14:00:42 +0000

Folks,

I think that a better approach is to update RFC 4443 so that it forbids the inclusion of extension headers in ICMP messages. We might make a few exceptions for messages like Echo Request.

This is what we actually do today.

                                                                                                                                     Ron

Juniper Internal

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Fernando Gont
Sent: Wednesday, May 29, 2019 3:48 AM
To: Ole Troan <[email-masked]>; Tom Herbert <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Conflicting requirements for sending ICMPv6 and EH scan?

On 29/5/19 03:35, Ole Troan wrote:
>> Assuming we do continue to perform the deep parse, then what should 
>> be done if we can't conclusively determine whether or not the packet 

Cheers,

--------------------------------------------------------------------
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=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=DBi3RHcqAEfpJf4TC5IS1lIF60xoxsS2VZHEin9GGKU&s=LZPoVghfCkUANAm1IXcUJuWVVzfPCiEuhIsfW6y0q8M&e=
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 May 2019 07:50:48 -0700

> I think that a better approach is to update RFC 4443 so that it forbids the inclusion of extension headers in ICMP messages. We might make a few exceptions for messages like Echo Request.
Ron,

I don't think that is practical nor desirable. For instance, RFC4443
recommends use of AH or ESP for security in sending ICMP.

> This is what we actually do today.
EH+ICMP does happen today. If someone enables segment routing to some
destination on a Linux device today, and ICMP error error needs to be
sent to the destination, then the routing header will be used with an
ICMP message. There are probably other cases as well.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 29 May 2019 15:31:41 +0000

Inline.....

Juniper Internal

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Wednesday, May 29, 2019 10:51 AM
To: Ron Bonica <[email-masked]>
Cc: Fernando Gont <[email-masked]>; Ole Troan <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: Conflicting requirements for sending ICMPv6 and EH scan?

Ron,

I don't think that is practical nor desirable. For instance, RFC4443 recommends use of AH or ESP for security in sending ICMP.

[RB] Do you know of any deployments that do this?

EH+ICMP does happen today. If someone enables segment routing to some
destination on a Linux device today, and ICMP error error needs to be sent to the destination, then the routing header will be used with an ICMP message. There are probably other cases as well.

[RB] Again, do you know of any deployments that do this?

Tom

> >> Yes, I think the approach is reasonable (and we've been doing it 
> >> for fourteen years anyway!).
> >
> >> be done if we can't conclusively determine whether or not the 
> >> packet contains an ICMP error (for instance we hit something like 
> >> an unrecognized next header or ESP)? Right now the ICMP error is 
> >> sent anyway, but strict adherence to RFC4443 might imply we shoudn't send.
> >
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=DBi3RHcqAEfpJf4TC5I
> S1lIF60xoxsS2VZHEin9GGKU&s=LZPoVghfCkUANAm1IXcUJuWVVzfPCiEuhIsfW6y0q8M
> &e=

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 May 2019 09:26:46 -0700

Ron,

Neither the standard nor implementations prevent use of EH+ICMP and I
have no data to say that it isn't in use or even uncommon. I believe
the consensus is that parsing extension headers to find the end
protocol to see if it's ICMP is reasonable and conformant. So this is
only an update to the comments to fix my problem; forcing ICMP packets
to never include EH would be a lot more work.

Thanks,
Tom

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 11:05:01 -0400

On 29/5/19 10:50, Tom Herbert wrote:
>> I think that a better approach is to update RFC 4443 so that it
>> forbids the inclusion of extension headers in ICMP messages. We
>> might make a few exceptions for messages like Echo Request.
>> 
> Ron,
> 

So essentially one would be open to establishing a SA with any potential
router on the Internet.

Even SEND sounds more realistic....

> EH+ICMP does happen today. If someone enables segment routing to
> some destination on a Linux device today, and ICMP error error needs
> to be sent to the destination, then the routing header will be used
> with an ICMP message. There are probably other cases as well.

This might seem yet another case for controlled environments....

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 May 2019 09:48:40 -0700

> Even SEND sounds more realistic....
Fernando,

You are either misinterpreting my comment or text in section 5.2 of RFC4443:

"ICMP messages may be subject to actions intended to cause the message
or the reply to it to go to a destination different from that of the
message originator's intention.  The protection against this attack
can be achieved by using the Authentication Header [IPv6-AUTH] or the
Encapsulating Security Payload Header [IPv6-ESP]."

So if security of ICMP is important, then use of AH is an _option_ to
address that. Regarless, the RFC clearly allows it.

Tom

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 02:52:28 +1000

> [RB] Again, do you know of any deployments that do this?

Hmm. Since ICMP messages are rate limited at the sender, aren't
reliably sent through acknowledgement and retransmission, and are
purposely blocked on occasion in the network, then their structure
could be less formal or strict with regards to use of EHs (i.e. more
strict about not using EHs). It's great if they're both sent and they
arrive, but they may be neither.

Regards,
Mark.