Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 May 2012 16:59:56 -0400

Earlier, Joel Halpern wrote:
> It seems that the right answer was discussed much earlier, namely
> changing the protocol behavior (a 6man activity) to tell hosts to
> reject RA and ND packets which were received in fragments.

Earlier, Ron Bonica wrote:
> I would be thrilled if the 6man WG would update RFC 4443 to say something like:
> "ICMPv6 packets MUST NOT be fragmented unless the ICMPv6 Type, Code, and Checksum 
> all fit in the first fragment".

I support Joel and Ron in this.  

A better approach for the RA Guard document would be:

1) to put together a separate I-D for 6MAN that says approximately 
   the above (and explains why).  There is probably a little text
   clarifying that any host receiving an RA that did not comply with
   the proposed new rule above MUST be dropped by that receiving host.

   One imagines this would not be controversial within 6MAN and could 
   proceed quickly.  If it were controversial there, that would 
   tend to indicate a significant problem with the current RA Guard text.

   This would be a more comprehensive protection.  Ultimately, the
   risk of unauthorised RA messages is a risk to the hosts, so host IPv6
   implementers have strong incentive to update their stacks quickly 
   once the IPv6 specifications are updated accordingly.  

2) in parallel with (1), revise the RA Guard I-D to either delete
   "Rule 4" (e.g. citing the proposed new rule above) or invert the
   meaning of Rule 4.  Either way, the objective would be that all 
   valid IPv6 packets are passed by an RA Guard all the time.

Yours,

Ran

PS:  It seems to me that the V6 OPS WG ought not be recommending 
     behaviours that violate the IPv6 specifications.  Instead, 
     if situations arise where V6 OPS thinks the specified behaviour 
     is either wrong or incompletely described, then someone should 
     propose an IPv6 specification update/edit/correction to the 6MAN WG.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 May 2012 20:18:44 -0300

>    the proposed new rule above MUST be dropped by that receiving host.

FWIW, something like that has already been published and presented at
the last IETF:

* <http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt>

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

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 31 May 2012 09:53:31 -0400

Fernando,

The problem that we are wrestling with isn't specific to RA Guard. The kind of fragmentation that we are discussing will cause problems for firewalls, in general. Therefore, we might want to request the following from 6man:

1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6 header, all extension headers, the ICMPv6 type, code, and checksum are included in the first fragment

2) Hosts MUST NOT send fragmented packets carrying any next-layer protocol unless the IPv6 header, all extension headers, the entire next-layer protocol header are included in the first fragment. TCP and UDP are examples of next-layer protocols.

                                             Ron
                                             <speaking as individual contributor>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fernando Gont
> Sent: Wednesday, May 30, 2012 7:19 PM
> To: RJ Atkinson
> Cc: [email-masked]
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-
> implementation-04.txt> (Implementation Advice for IPv6 Router
> Advertisement Guard (RA-Guard)) to Best Current Practice
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 31 May 2012 10:02:55 -0400

- I like that idea, since fragments have been a problem (from a security perspective, both v4 and v6). This writing seems to provide a good way to enable any middle box to be able to apply policies.  
- should the 6man mailing list be added to that thread?

Marc.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 May 2012 11:55:09 -0300

Hi, Ron,

On 05/31/2012 10:53 AM, Ronald Bonica wrote:
> The problem that we are wrestling with isn't specific to RA Guard.

We're kind of discussing to different, but entangled, problems:

a) Use of fragmentation in Neighbor Discovery
b) IPv6 header chains that span multiple fragments

Regarding "a)", use of fragmentation with ND prevents feature-parity
with IPv4: It becomes virtually impossible to e.g. perform Neighbor
Discovery inspection (a la arpwatch or the like)

Regarding "b)", it essentially prevents stateless filtering, and also
breaks stateless translators. And is not limited to ICMPv6, but to all
traffic. (please see below)

> Therefore, we might want to request the
> following from 6man:
> 
> 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6
> header, all extension headers, the ICMPv6 type, code, and checksum
> are included in the first fragment

This is a subset of "2)" below. Additionally, if you still allow
fragmentation, ND inspection (i.e. inspection of the ND packets
contents) is still virtually impossible -- and fragmentation is not
needed for ND, anyway. So one can safely forbid fragmentation with ND
(for the general case).

This is why I wrote
<http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt>

> 2) Hosts MUST NOT send fragmented packets carrying any next-layer
> protocol unless the IPv6 header, all extension headers, the entire
> next-layer protocol header are included in the first fragment. TCP
> and UDP are examples of next-layer protocols.

Fully agree. For instance, that's why we wrote:
<http://tools.ietf.org/id/draft-gont-6man-oversized-header-chain-01.txt>

My take is that these "packets with an IPv6 header chain that spans
multiple fragments" will be unreliable in the public Internet (stateless
firewalls and stateless translators).

Thanks,

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 31 May 2012 11:16:54 -0400

Fernando,

If I read what you are saying correctly, our request to 6man should say:

1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement or Redirect messages.

1) Hosts MUST NOT fragment any other ICMPv6 message unless the IPv6 header, all extension headers, the ICMPv6 type, code, and checksum are included in the first fragment

3) Hosts MUST NOT fragment packets carrying any next-layer protocol unless the IPv6 header, all extension headers, the entire next-layer protocol header are included in the first fragment. TCP and UDP are examples of next-layer protocols.

Do I have this right?

                                      Ron

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Thursday, May 31, 2012 10:55 AM
> To: Ronald Bonica
> Cc: Fernando Gont; RJ Atkinson; [email-masked]
> > Therefore, we might want to request the following from 6man:
> >
> and
> > UDP are examples of next-layer protocols.
> 
> multiple fragments" will be unreliable in the public Internet
> (stateless firewalls and stateless translators).
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 May 2012 12:50:35 -0300

Hi, Ron,

On 05/31/2012 12:16 PM, Ronald Bonica wrote:
> 1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router
> Advertisement, Neighbor Solicitation, Neighbor Advertisement or
> Redirect messages.

This one is correct.

Note that in draft-gont-6man-nd-extension-headers, we're currently
saying "SHOULD NOT", but this should probably be changed to "MUST NOT",
as you indicate.

> 1) Hosts MUST NOT fragment any other ICMPv6 message unless the IPv6

This one is a subset of "3)" below, so need for special requirements
here -- i.e., we don't need to make ICMPv6 a special case.

> 3) Hosts MUST NOT fragment packets carrying any next-layer protocol
> unless the IPv6 header, all extension headers, the entire next-layer
> protocol header are included in the first fragment. TCP and UDP are
> examples of next-layer protocols.

This is correct.

We have expressed this requirement (in
draft-gont-6man-oversized-header-chain-01.txt) as:

   All IPv6 packets MUST contain the entire IPv6 header chain within the
   first "assumed Path-MTU" bytes of the packet.  If a packet is
   fragmented, the first fragment of the packet (i.e., that with a
   Fragment Offset of 0) must contain the entire IPv6 header chain
   within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the
   packet.

> Do I have this right?

Yes.

Cheers,

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 31 May 2012 12:04:07 -0400

Wfm!

> Sent: Thursday, May 31, 2012 11:51 AM
> To: Ronald Bonica
> Cc: RJ Atkinson; [email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 May 2012 14:09:37 -0400

> saying "SHOULD NOT", but this should probably be changed to "MUST NOT",

Agree.  

"MUST NOT" seems to be functionally necessary here.

>   within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the

That seems OK at first reading.  

I hope there already is text that has the effect of requiring 
a receiving IPv6 node to drop any received ICMPv6 that hid 
behind a Fragment Header.  One imagines the actual requirement 
for receiving IPv6 nodes might be written more generically.

As an example to clarify things, it would not hurt to explicitly 
note that this does NOT preclude the use of TCP Jumbo data payloads, 
but instead merely requires that all *headers*, starting from IPv6 
base header and continuing up to & including the TCP header, 
be present in the 1st packet.

This means that the RA Guard document ought to:
(1) cite (normatively) draft-gont-6man-oversized-header-chain, 
(2) delete Rule 4 of the RA Guard draft (which is not needed), 
and 
(3) add clarifying text to the RA Guard draft noting that the 
    referenced 6MAN document ensures that RA messages that 
    try to hide behind a Fragment Header will be dropped 
    by the receiving IPv6 node.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 May 2012 15:52:48 -0300

Hi, Ran,

> "MUST NOT" seems to be functionally necessary here.

Ok, I will update the doc and resubmit, such that 6man wg is polled
about adoption of this I-D with this change 'in'.

Note: the only possible "issue" here is that with SEND, packets *might*
grow large enough to need fragmentation. However:

1) The aforementioned behaviour would be specified for traditional ND,
rather than SEND.
2) At least the packet sizes sampled in the SEND spec are not larger
than 1280 bytes
3) If you do deploy send, you don't really want to rely on
fragmentation. If you do, then an attacker could trivially "disable"
SEND by performing fragmentation (DoS) attacks.

-- Just wanted to double-check this with you before the s/SHOULD/MUST/
change.

> behind a Fragment Header.  

Such requirement is in draft-gont-6man-nd-extension-headers.
Essentially, draft-gont-6man-nd-extension-headers forbids the use of
fragmentation with ND, and hence this means that when it comes to ND
you'll always have the entire IPv6 header chain available in the same
packet (if you don't, the packet was fragmented, and you're required to
fragment it).

draft-gont-6man-oversized-header-chain tackles a more general problem:
since we cannot ban IPv6 fragmentation altogether for general traffic
(for obvious reasons), for the general case we require the first
fragment to include the entire IPv6 header chain (i.e., "put as many
headers as you want (including fragmentation)... but the entire IPv6
header chain must be available in the first fragment").

> One imagines the actual requirement

You mean this could/should be clarified in
draft-gont-6man-oversized-header-chain-01, or somewhere else?

>     by the receiving IPv6 node.

But if it's agreed that packets that do not contain the entire IPv6
header chain shouldn't be there, what would be the motivation for
allowing them through ra-guard? -- Put another way, if we include a
normative reference to draft-gont-6man-oversized-header-chain, this
implicitly mean that, even with rule #4 in, the posibility of false
positives is 0 (and OTOH, leaving rule #4 in allows ra-guard to protect
'legacy' implementations.

(Me just wanting to follow your reasoning here)

Thanks!

Best regards,

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 May 2012 16:32:35 -0400

> 1) The aforementioned behaviour would be specified for traditional ND,

OK.  As you say, it makes sense to except SEND from the restriction, 
since it provides stronger authentication already.

> -- Just wanted to double-check this with you before the s/SHOULD/MUST/

That sounds reasonable to me at first read, but one caveat.

CAVEAT:
I'm not a SEND expert. 
I don't know whether a SEND expert might have concerns.

> header chain must be available in the first fragment").

For the RA Guard problem, I strongly prefer the approach you indicate
is defined in draft-gont-6man-nd-extension-headers -- because it is
better scoped.  Also, the sender always knows the link MTU for directly 
attached links (i.e. always known for the ND case) and ND is always
link-local.  So there are fewer unknowns operationally.

I am not as enthusiastic about the *-oversized-header-chain approach,
which appears to have much broader scope, because a sending node 
can't reliably know the Path MTU, sadly, and because I know of 
some odd-sized IPv6 link MTUs in the deployed world.  Also, as I recall,
you identified some special cases where the Path MTU might be 
less than the theoretical IPv6 minimum MTU and yet the Path MTU 
could be valid per various other IETF (transition-related ??) specs.

However, I can tolerate *-oversized-header-chain, if that really 
is preferred collectively over the more focused *nd-extension-headers 
approach.

> draft-gont-6man-oversized-header-chain-01, or somewhere else?

...or in *-nd-extension-headers, as applicable.

> allowing them through ra-guard?

That logic seems to include a somewhat theoretical assumption -- 
namely that an RA Guard implementation built out of available
CPUs and available silicon will be able to read all of
the bytes in the IPv6 packet and will be able to do so at some
interesting fraction of line-rate for common interfaces.  In theory,
that might be true, and for some specific implementations 
it could be true, but it won't be universally true in practice.
For example, it is unlikely to be true anytime soon for 
very high speed Ethernet links.

In the real world, some (many ?) implementations of RA Guard 
will have an implementation-specific limit to packet inspection 
that is less than the Link MTU.  Such limits are commonplace, 
possibly universal.  Even "Deep Packet Inspection (DPI)" firewall 
implementations normally only can read several hundred bytes 
(perhaps 200 or 300) into a packet -- whereas a valid IPv6/Ethernet 
packet (e.g. ~1500 bytes long) legitimately might not reach
the final (TCP, UDP, ICMP) header by the point that the
implementation-specific DPI limit of the RA Guard implementation 
is reached.

So some (we hope not many) real world RA Guard implementations 
will not be able to figure out whether a particular valid IPv6 
packet is valid or not, due to implementation-specific limitations 
of that particular RA Guard implementation.  When an RA Guard can't
reliably figure out whether the packet is valid, the RA Guard should 
send the packet along -- on the principle of not dropping any 
valid IPv6 packets (aka: "do no harm").

Since the hosts will be protecting themselves from any RAs trying
to hide behind Fragment Headers, there is no risk to having 
Rule 4 either disappear or be changed to allow all packets
where the particular RA Guard implementation can't figure out
whether a given IPv6 packet is valid or not.

At a more architectural level, if the IPv6 specs need to change,
then I'd like to see those changes proposed and accepted by the
6MAN WG (or its successors) -- rather than having an IETF recommended
operational practice have the result of changing the IPv6 specs
without bothering to update the actual IPv6 specs.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 May 2012 22:14:46 -0300

Hi, Ran,

On 05/31/2012 05:32 PM, RJ Atkinson wrote:
>> Note: the only possible "issue" here is that with SEND, packets
>> *might* grow large enough to need fragmentation. However:
>> 
>> 1) The aforementioned behaviour would be specified for traditional
>> ND, rather than SEND.
> 

Well, in the case of SEND, one *might* want to relax the restriction to
"SHOULD". However, I'd note that having SEND rely on fragmentation seems
to me like a very bad idea: essentially, an attacker could perform a
fragmentation-based DoS attack against SEND, and hence nodes would
typically employ the malicious and non-authenticated information sent by
the attacker (unless there's no fall back for non-send nodes).

>> 2) At least the packet sizes sampled in the SEND spec are not
>> larger than 1280 bytes 3) If you do deploy send, you don't really
>> want to rely on fragmentation. If you do, then an attacker could
>> trivially "disable" SEND by performing fragmentation (DoS)
>> attacks.
>> 
[....]
> I don't know whether a SEND expert might have concerns.

I will drop a note to the authors of the SEND spec and ask for input...

>> draft-gont-6man-oversized-header-chain tackles a more general
>> problem: since we cannot ban IPv6 fragmentation altogether for
>> general traffic (for obvious reasons), for the general case we
>> require the first fragment to include the entire IPv6 header chain
>> (i.e., "put as many headers as you want (including
>> fragmentation)... but the entire IPv6 header chain must be
>> available in the first fragment").
> 
> For the RA Guard problem, I strongly prefer the approach you
> indicate is defined in draft-gont-6man-nd-extension-headers --
> because it is better scoped.  Also, the sender always knows the link
> MTU for directly attached links (i.e. always known for the ND case)
> and ND is always link-local.  So there are fewer unknowns
> operationally.

Well, draft-gont-6man-nd-extension-headers kind of tackles the
underlying problem behind filtering/monitoring ND-traffic.

OTOH, draft-gont-6man-oversized-header-chain tackles a related but
different problem (that's why it's not as scoped).

> I am not as enthusiastic about the *-oversized-header-chain
> approach, which appears to have much broader scope, because a sending
> node can't reliably know the Path MTU, sadly, and because I know of 
> some odd-sized IPv6 link MTUs in the deployed world.

Well, what *-oversized-header-chain essentially says is that if you
fragment your packets, the entire IPv6 header should be present in the
first fragment. As long as there is no intermmediate system that
fragments your datagrams *and* splits the IPv6 header chain into
multiple fragments, you're fine.

> Also, as I recall, you identified some special cases where the Path
> MTU might be less than the theoretical IPv6 minimum MTU and yet the
> Path MTU could be valid per various other IETF (transition-related
> ??) specs.

What can be less than the IPv6 minimum MTU is the advertised MTU in an
ICMPv6 PTB message (which would trigger the inclusion of a fragment
header in all further packets). However, the minimum MTU is still
considered to be 1280 bytes.

> However, I can tolerate *-oversized-header-chain, if that really is
> preferred collectively over the more focused *nd-extension-headers 
> approach.

I think that both documents complement each other. Since
*nd-extension-headers bans the use of fragmentation in ND, it not only
simplifies the implementation of ra-guard, but *also* enables
ND-monitoring (i.e., inspecting the contents of ND packets e.g. a la
arpwatch).

>>> This means that the RA Guard document ought to: (1) cite
>>> (normatively) draft-gont-6man-oversized-header-chain, (2) delete
>>> Rule 4 of the RA Guard draft (which is not needed), and (3) add
>>> clarifying text to the RA Guard draft noting that the referenced
>>> 6MAN document ensures that RA messages that try to hide behind a
>>> Fragment Header will be dropped by the receiving IPv6 node.
>> 
>> But if it's agreed that packets that do not contain the entire
>> IPv6 header chain shouldn't be there, what would be the motivation
>> for allowing them through ra-guard?
> 
> namely that an RA Guard implementation built out of available CPUs
> and available silicon will be able to read all of the bytes in the
> IPv6 packet and will be able to do so at some interesting fraction of
> line-rate for common interfaces.  In theory, that might be true, and
> for some specific implementations it could be true, but it won't be
> universally true in practice. For example, it is unlikely to be true
> anytime soon for very high speed Ethernet links.

Well, this is the reason for which the first version of
*nd-extension-headers tried to ban the use of all extension headers with
ND. But it was argued (in 6man) that of parsing the entire IPv6 header
chain at a layer-2 device was easily doable, and hence there was no need
to limit possible extensions of ND (based on ext headers).

In any case, if anything, this would be an argument to the extent to
which ra-guard is simple/possible to implement, rather than about
whether we should leave rule #4 in or out.

> In the real world, some (many ?) implementations of RA Guard will
> have an implementation-specific limit to packet inspection that is
> less than the Link MTU. 
[....]
> So some (we hope not many) real world RA Guard implementations will
> not be able to figure out whether a particular valid IPv6 packet is
> valid or not, due to implementation-specific limitations of that
> particular RA Guard implementation.

I would expect that RA-Guard implementation enforce a limit on the
number of ext headers that they process (rather than of "bytes" that are
"jumped over"). In that case, if they enforce some sensible limit (10?)
they could prevent possible DoS attacks while still allowing all
legitimate traffic.

> When an RA Guard can't reliably
> figure out whether the packet is valid, the RA Guard should send the
> packet along -- on the principle of not dropping any valid IPv6
> packets (aka: "do no harm").

My take is that those packets will not survive the public IPv6 Internet.
Stateless firewalls will block those packets when the
implementation-specific limit is hit.

> Since the hosts will be protecting themselves from any RAs trying to
> hide behind Fragment Headers, there is no risk to having Rule 4
> either disappear or be changed to allow all packets where the
> particular RA Guard implementation can't figure out whether a given
> IPv6 packet is valid or not.

I fully agree with this when it comes to updated host implementations.
However, if the rules are changed as you indicate, those "legacy"
implementations that still allow the use of fragmentation with ND would
remain vulnerable.

> At a more architectural level, if the IPv6 specs need to change, then
> I'd like to see those changes proposed and accepted by the 6MAN WG
> (or its successors) -- rather than having an IETF recommended 

I personally believe that the specs should be changed -- for instance,
we're pursuing that effort in 6man with
draft-gont-6man-oversized-header-chain (about which 6man should be
polled soon).

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1