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
<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 <http://www.insidethestack.com/>
------------------------------------------------------------------------
*From:* Ray Hunter <v6...@globis.net <mailto:v6...@globis.net>>
*To:* Nalini Elkins <nalini.elk...@insidethestack.com
<mailto:nalini.elk...@insidethestack.com>>
*Cc:* Brian E Carpenter <brian.e.carpen...@gmail.com
<mailto:brian.e.carpen...@gmail.com>>; 6man
<ipv6@ietf.org <mailto:ipv6@ietf.org>>; Fernando Gont
<fg...@si6networks.com <mailto:fg...@si6networks.com>>;
vishwas.man...@hp.com <mailto: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=>>
<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 <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=>
<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
------------------------------------------------------------------------
