[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices

On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:
> On 17/06/2015 07:02, Jen Linkova wrote:
>> https://tools.ietf.org/html/draft-wkumari-long-headers-03
>>
>> Comments are appreciated...
>
> In REQ-2 on HbH headers, you say:
>
>>  The forwarder MUST
>>  process each option as specified in Section 4.2 of [RFC2460].
>
> That aspect of RFC 2460 was fundamentally changed by RFC 7045.

Oh, very good point. Thanks for pointing this out. Looks like it does
cover our REQ2 (but requires different behavior).

So,  Section 2.1 RFC7045 says about *all* EHs:

"If a forwarding node discards a packet containing a standard IPv6
   extension header, it MUST be the result of a configurable policy and
   not just the result of a failure to recognise such a header. "

and then, in Section 2.1 for HbH:
"The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path. ".

I read this as 'if a router does not recognize/parse the HbH header,
it MUST not discard it unless there is an explicit policy configured.
It may just ignore it or send for "special processing" via slow path.

So it assumes that it is always safe to ignore HbH header (as if all
options in the header had highest-order two bits set to '00') while
our draft proposed quite different approach ("drop and send ICMP
back").

Ignoring HbH header seems to be reasonable and safe if we are sure
that every single existing or to be developed HbH option can be safely
ignored (or options which could be ignored must be in the very
beginning of the header...).

In the light of RFC7045 it looks to me that one possible approach for
REQ2 might be:
- if a forwarder can not parse the HbH header and there is no
explicitly configurable policy, it SHOULD
either:
   -- if the forwarder can not parse any of options or if all parsed
options have highest-order two bits set to '00') - ignore the header;
   -- if the forwarder was able to parse some of options and at least
one of the options has highest-order two bits set to smth except '00'
- discard the packet and send ICMPv6 message if Section 4.2 of RFC
2460 requires so (sending ICMPv6 MAY be subject to a configurable
policy)
or send it to slow path for full header processing (subject to a
configurable policy).

How does that sound?

> I'm sure other things in the long-headers draft need revising as a
> result of RFC 7045, since its whole topic is the handling of extension
> headers ("This document updates RFC 2460 to clarify how intermediate
> nodes should deal with such extension headers and with any that are
> defined in the future.")

Yes, we'll revise it, thanks for the comment.
>
> Y'all also need to take account of RFC 7112, which forbids fragmented
> header chains.

We do mention 7112 but I agree, we should explicitly mention that
header chain is limited by a packet size...Will update the doc.


-- 
SY, Jen Linkova aka Furry