[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Next message (by thread): [ipv6-wg] [news] Finnish IPv6 Launch Event on 8 June in Helsinki, Finland
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Brian E Carpenter
brian.e.carpenter at gmail.com
Thu Jun 18 03:31:39 CEST 2015
On 18/06/2015 04:54, Jen Linkova wrote: > 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"). 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. > >
- Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Next message (by thread): [ipv6-wg] [news] Finnish IPv6 Launch Event on 8 June in Helsinki, Finland
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]