But the reality of the situation is that much of the Internet appears to be
running where
"n is an arbitrary number picked out of the air by a vendor"
Or rather
"multiple arbitrary numbers"!
Yes?
Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com
________________________________
From: Ray Hunter <v6...@globis.net>
To: Nalini Elkins <nalini.elk...@insidethestack.com>
Cc: Brian E Carpenter <brian.e.carpen...@gmail.com>; 6man <ipv6@ietf.org>;
Fernando Gont <fg...@si6networks.com>; "vishwas.man...@hp.com"
<vishwas.man...@hp.com>
Sent: Thursday, June 6, 2013 9:42 AM
Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re:
draft-ietf-6man-ext-transmit-01)
IMVHO interpreting the text of the current drafts.
> Nalini Elkins <mailto:nalini.elk...@insidethestack.com>
> 6 June 2013 18:20
> So, if we are talking about the MTU of the local egress interface,
> then since, I believe, the minimum MTU size for IPv6 is 1,280, then
> all devices should be prepared to examine up to 1,280 bytes to get the
> L4 header?
Not quite.
AFAICS
1. All parsing engines should be able to parse at least 1280 bytes to
cover the minimum IPv6 MTU.
2. If all the local interfaces are Ethernet, and have an MTU set of
1500, the parsing engine on that box should be able to parse a full
Ethernet frame of 1500 bytes of payload..... and so on for devices
supporting links with larger MTUs, all the way up to jumbograms (if
supported on that device).
3. draft-ietf-6man-ext-transmit gives the option of not parsing
extension headers at all on high speed routers (only the hop by hop
option is supposed to be parsed by routers on the path). But neither
this draft, nor any other IETF draft that I know of, gives an option for
parsing an IPv6 header chain "just for the first n bytes", where n is an
arbitrary number picked out of the air by a vendor, whether that be 53,
256 or 1280.
regards,
RayH
>
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>
> ------------------------------------------------------------------------
> *From:* Ray Hunter <v6...@globis.net>
> *To:* Nalini Elkins <nalini.elk...@insidethestack.com>
> *Cc:* Brian E Carpenter <brian.e.carpen...@gmail.com>; 6man
> <ipv6@ietf.org>; Fernando Gont <fg...@si6networks.com>;
> vishwas.man...@hp.com
> *Sent:* Thursday, June 6, 2013 9:14 AM
> *Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re:
> draft-ietf-6man-ext-transmit-01)
>
> Nalini Elkins wrote:
> > >>> Some tricky and potentially malicious cases will be avoided by
> > forbidding very long chains of extension headers that need to be
> > >>> fragmented [I-D.ietf-6man-oversized-header-chain].
> > >
> > > I wonder if this is the place to define "very long"?
> >
> > >> I guess those two words can be deleted - the issue is only that the
> > header chain gets fragmented at all. The full discussion is in the
> > cited draft, of course.
> >
> > I know the draft that you have cited and they do not define "long"
> > either. There has been quite a bit of discussion about what "long"
> > means and IMHO somewhere, someone needs to take some kind of
> > reasonable stand.
> >
> Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually
> long" very accurately.
>
> I-D.ietf-6man-oversized-header-chain requires that "the first fragment
> of a fragmented datagram is required to contain the entire IPv6 header
> chain"
>
> So in other words, any packet parsing engine should be prepared to
> examine an entire single frame up to the MTU of the local egress
> interface, but should not be expected to maintain any state across
> multiple fragments.
>
> We might also benefit operationally from setting an additional limit on
> the length of the hop hop option header, which is theoretically meant to
> be processed by routers along the path. However, my guess is that is
> well beyond the author's original intentions for
> draft-ietf-6man-oversized-header-chain-02, which was more focussed on
> firewalls.
>
> >
> > >>The IETF hasn't done much about firewalls at all. This
> > search produces far more expired drafts than anything else:
> > >>
> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>
> >
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=
> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>>
> >
> > The reason I asked is because I think defining RFCs or rules for
> > firewalls is a really good thing to do but if the vendors are not in
> > the habit of having to be compliant, then why would they pay attention
> > to this draft that we are discussing? I actually think maybe an RFC
> > which explicitly talks about firewalls is probably a good thing to do.
> > Now, getting vendors to comply...
> >
> > Thanks,
> >
> > Nalini Elkins
> > Inside Products, Inc.
> > (831) 659-8360
> > www.insidethestack.com <http://www.insidethestack.com/>
> >
>
>
>
> Ray Hunter <mailto:v6...@globis.net>
> 6 June 2013 18:14
> Nalini Elkins wrote:
>>>>> Some tricky and potentially malicious cases will be avoided by
>> forbidding very long chains of extension headers that need to be
>>>>> fragmented [I-D.ietf-6man-oversized-header-chain].
>>> I wonder if this is the place to define "very long"?
>>>> I guess those two words can be deleted - the issue is only that the
>> header chain gets fragmented at all. The full discussion is in the
>> cited draft, of course.
>>
>> I know the draft that you have cited and they do not define "long"
>> either. There has been quite a bit of discussion about what "long"
>> means and IMHO somewhere, someone needs to take some kind of
>> reasonable stand.
>>
> Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually
> long" very accurately.
>
> I-D.ietf-6man-oversized-header-chain requires that "the first fragment
> of a fragmented datagram is required to contain the entire IPv6 header
> chain"
>
> So in other words, any packet parsing engine should be prepared to
> examine an entire single frame up to the MTU of the local egress
> interface, but should not be expected to maintain any state across
> multiple fragments.
>
> We might also benefit operationally from setting an additional limit on
> the length of the hop hop option header, which is theoretically meant to
> be processed by routers along the path. However, my guess is that is
> well beyond the author's original intentions for
> draft-ietf-6man-oversized-header-chain-02, which was more focussed on
> firewalls.
>
>>>> The IETF hasn't done much about firewalls at all. This
>> search produces far more expired drafts than anything else:
>>>> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=
>> <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>
>>
>> The reason I asked is because I think defining RFCs or rules for
>> firewalls is a really good thing to do but if the vendors are not in
>> the habit of having to be compliant, then why would they pay attention
>> to this draft that we are discussing? I actually think maybe an RFC
>> which explicitly talks about firewalls is probably a good thing to do.
>> Now, getting vendors to comply...
>>
>> Thanks,
>>
>> Nalini Elkins
>> Inside Products, Inc.
>> (831) 659-8360
>> www.insidethestack.com
>>
>
> ------------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
