Re: [v6ops] Extension Headers / Impact on Security Devices

[Brian E Carpenter <[e-mail]>]

On 18/06/2015 04:54, Jen Linkova wrote:
> On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter
> <[e-mail]> 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").

Right. And we can have that discussion, of course, but IMNSHO a firewall
should either let stuff through or drop it for a congigured reason; dropping
it because the product development manager made a lazy choice is not OK.

> 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...).

Well, we can't know today what sort of crazy option might be invented in
future; so the thinking behind draft-ietf-opsec-ipv6-eh-filtering
seems right to me. Maybe that's a draft you need to be tracking.

To be honest what I was thinking when we added discussion of HbH to
RFC 7045 was not so much fixing the slow routers, but warning the community
that "hop-by-hop" does not mean every hop. Fred would like to fix that
with his 6man draft, and I don't mean to attack that idea.

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

AND if the forwarder is trying to be a firewall or otherwise
wants to interfere. If not, just forward the packet, already!

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

As I said: if the forwarder insists on doing something, OK.

But we have to think for a typical use case: does it matter if a
forwarder simply ignores the HbH header? For example, for the
IntServ/RSVP case, it just makes that router transparent to
RSVP. That doesn't break RSVP; discarding the packet does. That
was the thinking behind RFC 7045.

    Brian

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