Subject: [v6ops] new draft: draft-taylor-v6ops-fragdrop

From: <[email-masked]>
Date: Tue, 16 Oct 2012 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please take a look at it and comment.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Oct 2012 11:20:06 -0700

This report is troubling to me. One of the unspoken tenets of
IPv6 is that it fixes fragmentation and reassembly, for example
by including a large-enough Identification field to avoid wrapping
issues at high data rates (see RFC4963). With this knowledge, a
reasonable response from a host that receives a Packet Too Big
message may be to begin fragmenting large packets (up to 1500
bytes) rather than reduce the size of the packets it sends.

If a stateful middlebox needs to inspect all fragments before
forwarding to the final destination, then it should do something
like Virtual Fragmentation and Reassembly and then pass the
fragments through to the final destination assuming filtering
rules are satisfied. Either that, or simply allow non-initial
fragments through and let the final destination take the
appropriate actions. The choice may be dependent on whether the
middlebox is located closer to the core or closer to the edge.

Taking away IPv6 fragmentation/reassembly removes an important
option that should be available to end systems. It would further
"dumb-down" the eventual deployment of IPv6 we would see, and
would make dealing with MTU diversity that much harder.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, October 16, 2012 5:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 
> 
> A new draft has been posted, at http://tools.ietf.org/html/draft-taylor-
> v6ops-fragdrop. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 16 Oct 2012 19:25:39 +0100

On 16/10/2012 19:20, Templin, Fred L wrote:
> This report is troubling to me.

yeah, i suspect that the root cause is that it's difficult to process
arbitrarily positioned tlv based headers in hardware.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Oct 2012 11:42:56 -0700

> From: Nick Hilliard [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2012 11:26 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; draft-taylor-v6ops-
> [email-masked]
> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 

Why not just let non-initial fragments through and then forward
or don't forward the initial fragment depending on whether it
contains enough information in tlv headers to permit a filtering
decision?

Fred

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 16 Oct 2012 19:44:35 +0100

> contains enough information in tlv headers to permit a filtering

i spot some DoSs there.

(don't get me wrong, btw - this stuff is hard)

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Oct 2012 11:49:40 -0700

> Sent: Tuesday, October 16, 2012 11:45 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]

DoS'ing whom - the end systems? End systems know when to flush
incomplete reassemblies. For middleboxes that sit in front of
"low-end" end systems, there is also still the option of
Virtual Fragmentation Reassembly.

Plus, if we can't rely on ICMP PTB and we can't rely on IPv6
fragmentation/reassembly, then all we are left with is 1280
and IPv6 is the new ATM...

Fred

---

From: David Farmer <[email-masked]>
Date: Tue, 16 Oct 2012 14:23:13 -0500

> contains enough information in tlv headers to permit a filtering

There are fundamental differences in the security threat models between 
a bank and a prison.

If what you are trying to do is prevent information leakage, things 
getting out, then the non-initial fragments could have valuable 
information that you don't want leaking, even if it is incomplete 
information.

Yes, encryption can deal with this issue, but were dealing with the same 
mentality that says you have to decrypt everything crossing the 
parameter to inspect everything going out or coming in.

In most situations I believe this is invalid reasoning, however I cannot 
say it is invalid in all situations.  I also believe the reasoning is in 
far more common use than the situations that actually justify it.

-- 
===============================================
David Farmer               Email:[email-masked]
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Oct 2012 12:36:34 -0700

> From: David Farmer [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2012 12:23 PM
> To: Templin, Fred L
> Cc: Nick Hilliard; [email-masked]; draft-taylor-v6ops-
> [email-masked]; David Farmer

Data exfiltration by an adversary at work within your own network?
Sounds like a good use case for Virtual Fragmentation Reassembly.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 16 Oct 2012 23:28:26 +0100

> incomplete reassemblies.

The intermediate systems.  Well, maybe the end systems too, but that's a
different issue.

The problem with the intermediate systems is how you handle the packets.
Most fast/dumb boxes are able to process fixed-shape packets in hardware
because ASICs are pretty good at that sort of thing.  If you need to
process TLVs at line rate and make forwarding decisions on that basis, then
you need much smarter hardware.  So the issue comes down to what happens
when you have a fast/dumb box forwarding ipv6 packets with interesting
headers, and the dumb box is expected to do some level of filtering.

For fragments, if your dedicated hardware doesn't handle them natively,
then you have a choice between:

- allowing them through always
- dropping them always
- dropping them after a certain rate limit
- punting them to a more intelligent part of the forwarding device

For punted packets, most vendors punt them to the management plane because
they don't have a dedicated path for handling packets which are difficult
to parse.  This creates a management plane DoS which can be mitigated by
rate limiting the punting process.  So you end up with either a management
plane DoS, or an initial fragment DoS, or both.

Now, you could argue that dumb fast boxes shouldn't attempt ipv6 acls in
the first place, but what do you do if you want to implement v6 iACLs to
protect your internal infrastructure from external attacks?  Do you allow
all fragments through and potentially compromise your network?  Or do you
drop all fragments because your routing iron only has the capability to
either accept all fragments or drop them all?

> For middleboxes that sit in front of

urgh, state.  As a general principal, the less state you have to deal with
in your intermediate systems, the better.

> and IPv6 is the new ATM...

We had problems with this for years in the ipv4 world.  IPv6 has made it
much worse by implementing a difficult-to-parse IP Options style header
mechanism and expecting that this is an integral part of the protocol.  We
fixed it in IPv4 by universally dropping packets with options and by
creating an expectation that this was acceptable.

IOW, there are large parts of the internet for which there is no good
solution to this problem.  I.e. any part which doesn't forward packets
using a highly intelligent packet processing core.

Nick

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Oct 2012 15:48:48 -0700

> in your intermediate systems, the better.

This is why you always see that horrible look splayed on my face whenever I am reminded of the discussion on this list prior to the drafting of RFC 6092 all those years ago.

--
james woodyatt <[email-masked]>
core os networking

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Oct 2012 16:19:40 -0700

> Sent: Tuesday, October 16, 2012 3:28 PM
> To: Templin, Fred L

Filtering near the edges is where we have stateful filters that
are good at managing state. "Stateless" filtering near the middle
has no choice but to pass the fragments always.
 
> in your intermediate systems, the better.

IPv6 nodes are required to reassemble at least 1500 bytes in
any event. That is for packets explicitly addressed to the node,
but also consider (temporary) fragment matching for packets
passing through the node, e.g. as done by VRF. Plus, when the
router gets a fragment, chances are very good that its brethren
are hot on its heels and will arrive or not very quickly. So,
its not a case of holding onto gobs of fragments indefinitely
and can be managed by reasonably good hardware. At least, I
have been informed by individuals working for major network
equipment vendors that their implementations can handle router
reassembly.

> creating an expectation that this was acceptable.

IPv6 fixes fragmentation and reassembly, whereas filtering routers
dropping fragments breaks it. IPv6 fragmentation is a necessary
part of the equation needed to support path MTU diversity. RFC4821
is another part, but there is no way for the network to know when
end systems are using it.   

> using a highly intelligent packet processing core.

Dropping fragments violates the end-to end principles, and negates
path MTU diversity. 1280 is too small of a size for us to lock into
"the matrix" once and for always.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Oct 2012 13:52:50 +0100

> has no choice but to pass the fragments always.

I understand, but this opens up an implicit DoS vector if you use iACLs on
your dumb/fast transit boxes to filter out external ipv6 traffic to core
infrastructure, because you will be forced to explicitly allow fragments.

> equipment vendors that their implementations can handle router

I'll believe this when I see it.  Not saying that this isn't the case, but
in all networking equipment I've ever dealt with, whenever I've heard about
statements like this, the list of caveats is a long as your arm.

> "the matrix" once and for always.

I agree.  All I'm saying is that most core infrastructure on the internet
does not have clever enough silicon to handle anything other than
fixed-format packet structures, and if we expect it to make sensible
decisions on TLV based packet header decoding, we're fooling ourselves.
This problem may be fixed in future if we move from dumb ASICs to smarter
silicon, but there will be a substantial core network upgrade cost
associated with this, and it will take many years to deal with.  In the
interim, operators will need to choose between passing fragments (i.e.
allowing core infrastructure DoS vectors) or dropping fragments (i.e.
breaking ipv6 in the general case).  Neither option is good.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Oct 2012 14:47:20 +0100

> breaking ipv6 in the general case).  Neither option is good.

as someone prompted offline (for which thanks!) I should be clear that this
is a platform specific issue related to the cisco pfc3b/3bxl which has
three modes for handling ipv6 fragments:

1. forward them to the RP for software processing
2. drop them, overriding ACLs
3. forward them, overriding ACLs

I mistakenly implied that this was a more general problem, for which apologies.

Nick

---

From: Warren Kumari <[email-masked]>
Date: Wed, 17 Oct 2012 10:03:15 -0400

> equipment vendors that their implementations can handle router

"can handle router reassembly" != "can handle router reassembly at line rate on multiple interfaces".

You really need this to be line rate on all interfaces, otherwise there is (obviously) a DoS vector here. Reassembly at 10G (or 100G) is distinctly non-trivial and requires A: large buffers, B: short timeouts, C: gets sad if not all bits go through the same device, D: state and E: hardware designed specifically for this. This is much more than packet comes in, packet goes out...

W

-- 
A. No
Q. Is it sensible to top-post?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 Oct 2012 08:39:13 -0700

You know, all of this discussion is moot. RFC2460, Section 5 says:

   "In order to send a packet larger than a path's MTU, a node may use
   the IPv6 Fragment header to fragment the packet at the source and
   have it reassembled at the destination(s).  However, the use of such
   fragmentation is discouraged in any application that is able to
   adjust its packets to fit the measured path MTU (i.e., down to 1280
   octets).

   A node must be able to accept a fragmented packet that, after
   reassembly, is as large as 1500 octets.  A node is permitted to
   accept fragmented packets that reassemble to more than 1500 octets.
   An upper-layer protocol or application that depends on IPv6
   fragmentation to send packets larger than the MTU of a path should
   not send packets larger than 1500 octets unless it has assurance that
   the destination is capable of reassembling packets of that larger
   size."

That means that a source node has every reason to expect that, if
it fragments a packet that is no larger than 1500 bytes, then the
destination will be able to reassemble it. Host fragmentation is
therefore an integral part of correct IPv6 operation, and that's
the law until someone writes a different one. Middleboxes therefore
have no basis for dropping fragments, unless they can through some
means be determined as malicious (e.g., VFR).

Thanks - Fred

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 17 Oct 2012 13:58:07 -0700 (PDT)

On Wed, 17 Oct 2012, Warren Kumari wrote:
> > I have been informed by individuals working for major network 
> You really need this to be line rate on all interfaces, otherwise 
> there is (obviously) a DoS vector here.  Reassembly at 10G (or 
> 100G) is distinctly non-trivial and requires A: large buffers, B: 
> short timeouts, C: gets sad if not all bits go through the same 
> device, D: state and E: hardware designed specifically for this. 
> This is much more than packet comes in, packet goes out...

Excuse me, maybe I'm as dumb as a post, but .... why in the world 
are participants in this thread posing this as problem for the core?

Except for packets specifically destined for core infrastructure 
itself --- and those, surely, are not arriving at line rate -- the 
core has no reason to do anything other than just pass the fragments 
on and let edge devices deal with them.

Indeed, the draft itself states that "IPv6 datagrams with 
fragmentation headers are a non-issue in the core of the internet, 
where fragments are routed just like any other IPv6 datagram.  
However, fragmentation creates operational ssues at the edge of the 
network that may lead to administratively imposed filtering or 
inadvertent failure to deliver the fragment to the application."

//cmh

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Oct 2012 22:42:54 +0100

> You know, all of this discussion is moot. RFC2460, Section 5 says:
[...]
> means be determined as malicious (e.g., VFR).

We're all agreed that legitimate fragments should get through.  But there
is a large body of installed hardware out there in the core of the Internet
which has exactly the following options for dealing with ipv6 fragments:

> 1. forward them to the RP for software processing, which will cause a
> management plane DoS

> 2. drop them unilaterally, implicitly overriding all v6 ACLs, breaking
> IPv6 fragmentation

> 3. forward them unilaterally, implicitly overriding all ACLs, opening up
> an infrastructure DoS vector

None of these are pleasant options.

It's not a moot point: it's just a matter of the equipment not matching up
with the requirements of the RFCs and is a serious practical problem for
operators which use older equipment.  So how do we deal with it?  Does it
deserve a mention in the draft, with recommendations on what to do, or
would it be better to ignore the problem as it's a vendor/device specific
issue?

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 Oct 2012 15:26:12 -0700

> Sent: Wednesday, October 17, 2012 2:43 PM
> To: Templin, Fred L

In order to correctly observe the standards, core routers have no
option other than to simply forward any IPv6 fragments that are
"just passing through" - regardless of any configurable options
available on certain vendor products.

IPv6 fragmentation and reassembly is an end-to-end function, and
according to the end-to-end principles the function is best
implemented either within the end system or as close to the end
system as possible. The core needs to let the edge devices and
end systems deal with fragments, and even if fragments are passed
all the way through to the end system without prior examination
end systems nowadays have host-based firewalls.

I think we may be over-thinking this. Vendor equipment needs
to observe the standards in order to claim compliance. Broken
equipment should be identified and reported when it does not.

Fred

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Oct 2012 23:36:10 +0100

On 17/10/2012 23:26, Templin, Fred L wrote:
> Vendor equipment needs

So, is it appropriate to name broken kit in the draft?  I haven't formed an
opinion on this.  Naming and shaming brings up all sorts of issues.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 Oct 2012 15:46:36 -0700

> Sent: Wednesday, October 17, 2012 3:36 PM
> To: Templin, Fred L

I really don't know what is the right answer to that.

One thing that is missing from the draft however is that IP
tunnels are another mildly important class of "application"
that cannot reduce the size of the packets they send down to
1280. For them, it is either fragmentation or black hole...

Thanks - Fred

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Oct 2012 00:07:42 -0700

> available on certain vendor products.
The focus on core devices is misguided imho... The services edge of my 
network where both connections terminate and policy is applied may be 
substantially higher capacity than the backbone of many networks it is 
exposed to this issue. Given that I am an end-site all traffic carried 
on a backbone is either coming from or in bound to an end system on our 
network.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Oct 2012 00:12:26 -0700

> are participants in this thread posing this as problem for the core?
The fact that  high capacity requirements exsit does not imply that it a 
problem for the core.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Oct 2012 09:26:37 +0100

On 18/10/2012 08:07, joel jaeggli wrote:
...
> on a backbone is either coming from or in bound to an end system on our

Yes, and as far as I can tell the problems arise with site-boundary
devices that attempt to indulge in deep packet inspection and are
stymied by extension headers and/or fragments. Load balancers have
similar difficulties. These devices do violate the letter or spirit
of RFC 2460, but that's life.

(The fact that RFC 2460 does not spell out behaviour for extension headers
not mentioned in RFC 2460 is why I wrote draft-carpenter-6man-ext-transmit.
But that will not magically change the code in firewalls.)

Core routers just route packets. ECMP/LAG might not work optimally in some
cases, but that doesn't break e2e connectivity.

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Thu, 18 Oct 2012 13:37:19 -0400

> are participants in this thread posing this as problem for the core?

Er, we are not necessarily talking about problems for the core -- a number of folk have 10G at the "edge" / security boundary of the network, and this is where filtering type decisions happen.

Even if you are not anywhere near approaching line-rate, you need to be sure that the device can manage to do this work *at* line rate.  If you usually only push 1Mbps through your e.g 1Gbps interface, if the device can only of reassembly with small fragments at 100Mbps, you have dropped your DoS ability to 100Mbps.

> itself --- and those, surely, are not arriving at line rate 

Yes, and part of the reason that packets are not reaching the core infrastructure at line rate is because operators have the ability to examine traffic destined for the core infrastructure and filter / rate-limit it to something reasonable. I may want to allow e.g traceroute to "core" stuff and toss that in one rate-limit bucket, but never allow SSH towards my core.  If I have fragments I have no way of knowing what they are supposed to be part of, and so, er… 

> -- the 

Ah, but these are edge devices….

> inadvertent failure to deliver the fragment to the application."

Yup.
W

--
"Working the ICANN process is like being nibbled to death by ducks,
it takes forever, it doesn't make sense, and in the end we're still dead in the water." 
    -- Tom Galvin, VeriSign's vice president for government relations.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 18 Oct 2012 13:37:55 -0400

On Oct 18, 2012, at 3:12 AM, joel jaeggli <[email-masked]> wrote:

> The fact that  high capacity requirements exsit does not imply that it a problem for the core.

Yah, what he said…

W

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Oct 2012 10:48:37 -0700

> 1280. For them, it is either fragmentation or black hole...

This is examined further in my draft ("Operational Issues with
Tunnel Maximum Transmission Unit (MTU)") that saw list discussion
prior to IETF84:

https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/

The draft now notes the fragment dropping behavior discussed in
'draft-taylor-v6ops-fragdrop', and also suggests a way out of
the mire for tunnels that need to use some form of fragmentation.

Once again, tunnels are an important class of "application"
that cannot do without some form of fragmentation capability
for the tunneled packets, since they have no way of reducing
the size of the packets they send down to 1280.

Thanks - Fred

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Oct 2012 09:31:21 +1100

repl: bad addresses:
	C. M. Heard <[email-masked]> -- no at-sign after local-part (<)

In message <[email-masked]>, Warren Kumari writes:
> 
> Yes, and part of the reason that packets are not reaching the core infrastr=
> ucture at line rate is because operators have the ability to examine traffi=
> c destined for the core infrastructure and filter / rate-limit it to someth=
> ing reasonable. I may want to allow e.g traceroute to "core" stuff and toss=
>  that in one rate-limit bucket, but never allow SSH towards my core.  If I =
> have fragments I have no way of knowing what they are supposed to be part o=
> f, and so, er=85 =

So you want allow fragmented ICMP directed at core routers through and are worried
that some non initial TCP fragments might make it through.  As far as I can tell
letting through non initial TCP fragments doesn't increase your risk or attack
surface at all.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Oct 2012 11:46:31 +0100

> letting through non initial TCP fragments doesn't increase your risk or attack

other than causing bandwidth / pps DoS attacks, or alternatively tickling
obscure ipv6 stack bugs, no.  At least in theory.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 19 Oct 2012 11:11:54 -0700

> obscure ipv6 stack bugs, no.  At least in theory.

There's no excuse for broken IPv6 stacks that can't handle
fragmentation and reassembly. About DoS concerns, if the
network is going to intentionally break frag/reass out of
concern for edge devices that might not be able to handle
the load, then that is very bad for applications that cannot
reduce the size of packets they send down to 1280. Again,
tunnels fall into that category.

So, if tunnels cannot rely on ICMP PTB and also cannot rely
on IPv6 frag/reass then there is only one option remaining:

https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

Fred

---

From: Tom Taylor <[email-masked]>
Date: Fri, 19 Oct 2012 14:56:05 -0400

> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
...
which, as a matter of fact, came up briefly in the Interim Meeting 
discussion.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 19 Oct 2012 13:17:47 -0700

> which, as a matter of fact, came up briefly in the Interim Meeting

Thanks Tom; that is interesting.

Here also is another one on "Operational Issues with Tunnel Maximum
Transmission Unit (MTU)" - I have just updated it to cite 'fragdrop':

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Oct 2012 15:42:48 -0700

> of RFC 2460, but that's life.

Life's a b*tch for such devices. Let's keep it that way. ;-)

Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 19 Oct 2012 20:49:41 -0400

> letting through non initial TCP fragments doesn't increase your risk or attack

Ah, sorry, I guess I was unclear --  the connection from the data plane to the control plane is much much smaller than the data plane interfaces. This means that I need to protect the CP / CP interface by classifying and filtering / policing / rate-limiting traffic before it hits the CP interface. This means that I need to be able to examine the traffic to classify it. If I get a fragment, I have no way of knowing what it is for, and so have no way of knowing which rate-limiter to apply. This means I can a: just drop it, b: guess at a classification, c: have a classifier for all fragments or d: just accept all frags.

This is part of a more general problem -- if I have a router with a 10G interface facing "the Internet"[0] and e.g a webserver connected behind it with a 1G interface I'd like to make sure that only port 80/443 traffic is vying for the limited bandwidth. As I cannot reassemble on the router, I cannot classify what non-initial fragments are to know if they should be allowed.
Yes, an attacker can (obviously) still DoS me with >1Gbps of traffic on port 80, but at least I can filter out the stupid attacks on other ports (which works surprisingly well :-P)

W 

[0]: any network filled with badness...

--
Curse the dark, or light a match. You decide, it's your dark.
                -- Valdis Kletnieks

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 20 Oct 2012 11:42:39 -0700 (PDT)

On Fri, 19 Oct 2012, Warren Kumari wrote:
> Ah, sorry, I guess I was unclear -- the connection from the data 
> plane to the control plane is much much smaller than the data 
> plane interfaces. This means that I need to protect the CP / CP 
> interface by classifying and filtering / policing / rate-limiting 
> traffic before it hits the CP interface. This means that I need to 
> be able to examine the traffic to classify it. If I get a 
> fragment, I have no way of knowing what it is for, and so have no 
> way of knowing which rate-limiter to apply. This means I can a: 
> just drop it, b: guess at a classification, c: have a classifier 
> for all fragments or d: just accept all frags.
> 
> This is part of a more general problem -- if I have a router with 
> a 10G interface facing "the Internet"[0] and e.g a webserver 
> connected behind it with a 1G interface I'd like to make sure that 
> only port 80/443 traffic is vying for the limited bandwidth. As I 
> cannot reassemble on the router, I cannot classify what 
> non-initial fragments are to know if they should be allowed. Yes, 
> an attacker can (obviously) still DoS me with >1Gbps of traffic on 
> port 80, but at least I can filter out the stupid attacks on other 
> ports (which works surprisingly well :-P)

Circling back to my original comments about this draft, this is 
precisely the sort of information that needs to be added to Section 
2.1 to justify the assertion that "some cases will remain where 
legitimate fragments are discarded for legitimate reasons."

(FWIW, I am not sure that I agree that the reasons for discarding 
legitimate fragments are actually legitimate, but Warren Kumari's 
analysis does explain why some people do it.  It may or may not be 
in scope for the draft to suggest less destructive ways for 
operators to solve this class of problems.)

//cmh

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Oct 2012 12:44:27 +0100

On 19/10/2012 19:11, Templin, Fred L wrote:
> fragmentation and reassembly.

Here is a pile of excuses which many smaller providers find compelling
enough to agree with:

http://www.ebay.com/sch/i.html?_nkw=cisco+sup720

This kit is cheap, will drive 10G ports, provides good 1G density and does
all sorts of useful packet hackery.  As a result, this kit is very widely
deployed and will continue to be for many years.

So, what do we do?  Do we:

- ignore the problem
- issue generic advice
- name and shame
- other

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Oct 2012 14:44:27 +0200 (CEST)

> So, what do we do?  Do we:

Another data point:

<http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html>

So quite a lot of people running SUP720 will in the end disable IPv6 
fragment acl:s using the command provided. Quite a few others will not 
know about this and will thus give very different service to packets with 
fragmentation header and those without fragmentation header.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Mon, 22 Oct 2012 09:42:36 -0700

>> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

They can implement fragmentation in their upper layer encapsulation 
rather than using the ip fragmentation header and two or more fragmented 
ip datagrams in addition to seal, SSL/TLS-vpn's and SSTP have to do the 
same thing...
>> .

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Oct 2012 10:46:16 -0700

Hi Joel,

> joel jaeggli
> Sent: Monday, October 22, 2012 9:43 AM
> To: Tom Taylor
> Cc: [email-masked]

Do you know whether the DoS considerations discussed in this thread
apply also for SSL/TLS and SSTP when there is fragmentation in the
upper layers?

Thanks - Fred

---

From: joel jaeggli <[email-masked]>
Date: Mon, 22 Oct 2012 11:27:46 -0700

> apply also for SSL/TLS and SSTP when there is fragmentation in the
Speaking entirely for my own case the reason we actually use the 
stateless l3/l4 hash on our edge in front of a stateful edge that 
therefore has issues with hashed fragements ending up on different load 
balancers is becuase we have to load-balance SSL.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2012 05:28:15 -0300

Hi, Fred,

On 10/16/2012 03:20 PM, Templin, Fred L wrote:
> issues at high data rates (see RFC4963).

-- that's assuming the fragments don't go trough a translator...
Otherwise, the "effective" Frag-ID length is still 16 bits.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2012 05:30:01 -0300

>> contains enough information in tlv headers to permit a filtering

This is no different than the attacker sending non-initial fragments in
the first place....

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2012 05:31:54 -0300

> and IPv6 is the new ATM...

... and that's assuming no translators, and that the IPv6 Internet
really complies with the minimum IPv6 MTU (something that some argue
that it's not the case).

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Oct 2012 17:39:23 +0900

> So, what do we do?  Do we:

Other. Document that some networks drop fragments, the reasons why they do
so, and the impact on applications, but provide no advice.

It's unlikely that this group, let alone the IETF, would agree on what
advice to give (at least this decade), but I think it is the responsibility
of an operations group to document real operational issues, so the rest of
the community, including application developers and protocol developers,
can be made aware of it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Oct 2012 17:49:28 +0900

> legitimate fragments are discarded for legitimate reasons."

Suppose that you have packet filters at the edge of your network, and none
of your current code can look beyond the first next header value when doing
packet filtering at the edge. What do you do?

- Drop all fragments, no matter what they are
- Allow all fragments, no matter what they are
- Replace all the hardware
- Not deploy IPv6

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2012 05:51:34 -0300

> letting through non initial TCP fragments doesn't increase your risk or attack

If the end-system does not implement RFC5722, then allowng non-initial
fragments might still mean you're not filtering what you expected to be
filtering.

FWIW, we seem to be converging towards RFC5722, but that doesn't mean
everyone is there (e.g., see:
<http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html>).

Cheers,

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 23 Oct 2012 15:50:09 +0000

> really complies with the minimum IPv6 MTU (something that some argue

One could argue that IPv6 setting a minimum MTU and placing requirements on the underlying link layers is ill-considered. The underlying link layers are what they are. Some of the more amazing bits of 6lowpan are driven by that mismatch between IPv6 and 802.15.4.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Oct 2012 09:08:25 -0700

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 8:50 AM
> To: Fernando Gont
> Cc: Templin, Fred L; [email-masked]; draft-taylor-v6ops-
> [email-masked]
> One could argue that IPv6 setting a minimum MTU and placing requirements
> on the underlying link layers is ill-considered. The underlying link
> layers are what they are. Some of the more amazing bits of 6lowpan are
> driven by that mismatch between IPv6 and 802.15.4.

Setting the minimum MTU on a tunnel has another problem; for example,
what if that tunnel (tunnel 'A') enters another tunnel (tunnel 'B')
that also sets the minimum MTU? The 1280 packets encapsulated by
'A' show up at 'B' as (1280 + 40) = 1320 packets which are then are
dropped at 'B' because they are too big. Then, if the ICMP PTBs
generated by 'B' are lost on the return path to 'A' -> black hole.

Picking a fixed size 'S' for a tunnel always runs the risk that
that size will be wrong for some paths. Setting the MTU to
infinity and performing subnetwork adaptation when necessary
avoids the black holes.

Thanks - Fred

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 24 Oct 2012 13:49:54 -0700

On Oct 23, 2012, at 1:39 AM, Lorenzo Colitti wrote:

> Other. Document that some networks drop fragments, the reasons why they do so, and the impact on applications, but provide no advice.

+1

> It's unlikely that this group, let alone the IETF, would agree on what advice to give (at least this decade), but I think it is the responsibility of an operations group to document real operational issues, so the rest of the community, including application developers and protocol developers, can be made aware of it.

+1 on documenting known issues to make others aware

- merike

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Oct 2012 01:41:27 -0700 (PDT)

Hi,

----- Original Message -----
> From: Merike Kaeo <[email-masked]>
> To: Lorenzo Colitti <[email-masked]>
> Cc: V6 Ops <[email-masked]>
> Sent: Thursday, 25 October 2012 7:49 AM

I think there should be advice. If the IETF has seen fit to make

fragmentation a capability of IPv6, then I think that is inherently saying
that the IETF strongly suggests if not requires forwarding rather than
dropping of fragments for successful IPv6 operation. This seems to me to
be an RFC2775 Internet Transparency issue.

Alternatively, if fragments are more trouble than they're worth,
they should be deprecated. 

> advice to give (at least this decade), but I think it is the responsibility of 
> an operations group to document real operational issues, so the rest of the 
> community, including application developers and protocol developers, can be made 
> aware of it.
> 

It seems to me that developing an application that may be used over the

Internet involves developing for the worst case, not the best. If a small
but significant enough portion of sites on the Internet drop fragments, then
applications will be developed to avoid using fragments. Once applications
avoid using fragments to suit some sites on the Internet, then all sites
on the Internet may as well drop them, because they've been rendered useless.

---

From: Czerwonka Michał - Hurt TP <[email-masked]>
Date: Thu, 25 Oct 2012 08:53:50 +0000

"..., they should be deprecated " and increase the MTU on the Internet,now the minimum MTU is 8000. We forget about the fragmentation.

BR,
Mcz

-----Wiadomość oryginalna-----
Od: [email-masked] [mailto:[email-masked]] W imieniu Mark Smith
Wysłano: 25 października 2012 10:41
Do: Merike Kaeo; Lorenzo Colitti
DW: V6 Ops
Temat: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Hi,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2012 10:45:05 +0100

> be an RFC2775 Internet Transparency issue.

How about the combination of RFC 4890 and draft-carpenter-6man-ext-transmit
(the latter is on the 6man agenda in Atlanta)?

> they should be deprecated.

There are days when I think that's right.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Oct 2012 07:22:22 +1100

In message <[email-masked]>, Mark Sm
ith writes:
> > =
> > =
> > =
> >>  So, what do we do?=A0 Do we:
> >> =
> 
> >>  - ignore the problem
> >>  - issue generic advice
> >>  - name and shame
> >>  - other
> >> =
> 
> >>  Other. Document that some networks drop fragments, the reasons why they=
>  do =
> 
> > =
> >=A0
> they should be deprecated.=A0
> 
> >>  It's unlikely that this group, let alone the IETF, would agree on what=
> =A0
> 
> > advice to give (at least this decade), but I think it is the responsibili=
> ty of =
> 
> > an operations group to document real operational issues, so the rest of t=
> he =
> 
> > community, including application developers and protocol developers, can =
> be made =
> 
> > aware of it.
> >=A0
> 
> on the Internet may as well drop them, because they've been rendered useles=
> s.

Or they learn to adapt and use fragments where they work.  DNS clients
do this today.  They get stuck behind equipment that:

	* drops packets > 512 bytes
	* drops fragments
	* drops EDNS packets
	* drops packets with DO set
	* drops packets where the initial fagment doesn't arrive first

The clients adapt the queries they make to get responses back.

They work much more efficiently however if they can get fragmented EDNS
responses back.
 
> > =
> > =

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 26 Oct 2012 00:32:36 +0200 (CEST)

> They work much more efficiently however if they can get fragmented EDNS

What about DNSSEC ? Seems like there's a problem if the fragmentation 
does not work correctly: https://tnc2012.terena.org/getfile/1603

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 26 Oct 2012 01:30:12 +0200 (CEST)

> +1 on documenting known issues to make others aware

+1 on documenting, maybe worth adding to the section 2.2 a few more 
protocol case studies:

http://www.ietf.org/mail-archive/web/ipsec/current/msg07749.html
http://www.ietf.org/proceedings/71/slides/radext-4.pdf
http://support.microsoft.com/kb/244474

Alongside with that, also probably something like 
http://tools.ietf.org/html/rfc4347#section-4.2.3 could be also referenced 
as an example of application protocol's approach to fragmentation, 
alongside with 
http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00, 
http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-03,

This might help future app protocol writers' design choices, even if the 
document does not give the explicit advice (the fact on which I do not 
have an explicit opinion).

--a

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Oct 2012 16:51:14 -0700

I'm not sure whether noting the issue is critical or not, but tonly one 
of these examples is useful, IMO, as noted below:

On 10/25/2012 4:30 PM, Andrew Yourtchenko wrote:
...
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07749.html

This one seems useful to the point being discussed (of "drop all" 
fragment cases in the wild).

> http://www.ietf.org/proceedings/71/slides/radext-4.pdf

The above is more about trying to avoid fragmentation than any specific 
reason that fragmentation is a problem. Fragmentation is known to 
increase probability of drop (opportunity for reassembly overload, 
increased exposure to the impact of a packet drop). This example isn't 
directly about "drop all" cases, though.

>From that link:

"Because UDP is a connectionless protocol, fragmented UDP packets will 
be dropped if they arrive at the destination out of order. "

1) because UDP is connectionless, UDP packets should be tolerated out of 
order

2) fragments should already be tolerated out of order

So I can't understand why fragmented UDP packets should be dropped if 
they arrive out of order except as an implementation error.

Is this being noted as "bad advice arising from an implementation 
error"? If not, then it might not be useful to include.

> http://tools.ietf.org/html/rfc4347#section-4.2.3 could be also
> referenced as an example of application protocol's approach to
> fragmentation, alongside with

That advice presumes that the fragment size can be detected by the 
application; this is sometimes not the case. If such are being noted, 
the it might be useful to also at least recommend PLPMTUD (RFC 4821).

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Oct 2012 11:18:18 +1100

In message <alpine.DEB.2.02.1210260013030.15761@ayourtch-lnx>, Andrew Yourtchen
> does not work correctly: https://tnc2012.terena.org/getfile/1603

Which looks at a single query / response rather than a complete
system.  There are nameservers that do not respond to EDNS packets.
There are firewall that do not pass DNS/UDP packets bigger than 512
bytes.  These two issues overwhelm any issues due to fragmentation.

Nameserver vendors need to deal with these issues as they exist in
the real world ever if there isn't a RFC which says how to deal
with them.

Named sends EDNS@4096, EDNS@512 and plain DNS queries when resolving
queries.  It does this with sub second retry timeouts.  Most referrals
do not require fragmentation.  If there is not enough space in the
UDP response the server falls over to TCP.   Named drops the optional
parts of DNSKEY/DS responses reducing the likelyhood of fragmentation.
Named drops optional parts of responses when it sees a EDNS@512
query reducing the likelyhood of TCP fallback.

    isc.org referral w/ dnssec is 681 bytes from the root servers
    isc.org referral w/ dnssec is 514 bytes from the org servers
    the isc.org dnskey response is 463 bytes from the isc.org servers
    the org dnskey response is 1334 or 1723 bytes depending apon
	which nameserver impementatin you hit
    the root dnskey response is 736 bytes
    a nxdomain response for sdlkfhadslhasjdhgfjgask is 652 bytes (NSEC)
    a nxdomain response for sdlkfhadslhasjdhgfjgask.org is 1021 bytes (NSEC3)

Both the server and clients sides can limiting the sizes of UDP
responses being sent.  If you are validating and are stuck behind
a firewall that you can't change that blocks fragmented responses
you can tell the nameserver to announce a smaller EDNS UDP buffer
size that is unlikely to cause fragmentation.  Unless you are
validating plain DNS responses from signed zones do not cause any
issues.

In practice you get an occasional slow down due to fragmentation
when validating if you havn't fixed your local firewall or tuned
your nameserver to account for the firewall.

There is code (unreleased) that will do EDNS@4096, EDNS@1432 ([46]
in [46]), EDNS@1232 (IPv6 network MTU), EDNS@512 (stupid firewalls)
and plain DNS (even stupider firewalls / broken servers).  A little
bit of extra state per server talked to is used to remember this
across multiple queries.   Named already tracks response times.

Mark

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Oct 2012 22:19:16 -0300

>> Other. Document that some networks drop fragments, the reasons why they do so, and the impact on applications, but provide no advice.

If we can converge on some advice, I think it would be appropriate to
give it.

i.e., as a group, do we have a take on what'd be the most appropriate
thing to do wrt fragments?

Documenting this issue is good, but not giving any advice looks a bit
like hand-washing (or whatever you use in English for referring to the
act of not doing anything about something that deserves it :-) ).

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 10:53:26 +0900

On Thu, Oct 25, 2012 at 5:41 PM, Mark Smith <[email-masked]>wrote:

> I think there should be advice. If the IETF has seen fit to
> make fragmentation a capability of IPv6, then I think that is inherently
> saying

I agree that there should be advice, but unfortunately, I don't see a way
to do that.

For example, I personally think that fragments are more trouble than
they're worth, they don't work in today's Internet (IPv4 *or* IPv6), create
security issues (see e.g., Fernando's issues with fragmented RAs, plus an
history of security issues in fragment-handling code) and that applications
are much better off implementing their own fragmentation above UDP or
whatever else they may use. Unfortunately, it doesn't seem likely that this
working group will reach consensus on such a recommendation.

On the other hand, giving the opposite advice, and saying "fragmentation is
required and fragments MUST always be allowed" is out of touch with
reality, because current implementations and network designs are not
capable of doing this, and is therefore useless because operators can't do
what implementations are not capable of. I doubt we'll reach consensus on
such a recommendation either.

As always, the danger in trying to reach consensus on a controversial topic
is that of endlessly discussing the issue, which makes it impossible to
make a useful contribution to it. The way I see it, if we can't reach
consensus, it's better to punt entirely and at least issue a statement
about the issues. At least we will have done something useful. If we get
deadlocked forever in trying to decide what the right thing to do is, we
will get nothing useful done at all.

> It seems to me that developing an application that may be used over
> the Internet involves developing for the worst case, not the best. If a
> small
> but significant enough portion of sites on the Internet drop fragments,
> then applications will be developed to avoid using fragments. Once
> applications avoid using fragments to suit some sites on the Internet, then
> all sites on the Internet may as well drop them, because they've been
> rendered useless.
>

I agree. But on the other hand, the data presented in this draft shows
clearly that what you describe ("a small but significant enough portion of
sites on the Internet drop fragments") is true today (actually, it's not
even "small"). So fragments have already been rendered useless in the
general case. But some of the reactions to the draft were, "That's
incorrect and it will break things. The operators filtering fragments
likely don't know that what they're doing is bad, and once we explain that
to them, they will fix it".

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Oct 2012 09:51:59 -0300

On 10/25/2012 10:53 PM, Lorenzo Colitti wrote:
> they're worth, they don't work in today's Internet (IPv4 *or* IPv6),
> create security issues (see e.g., Fernando's issues with fragmented RAs,
> plus an history of security issues in fragment-handling code) and that
> applications are much better off implementing their own fragmentation
> above UDP or whatever else they may use. 

I'd mostly say "+1" with everything you've said above.

> Unfortunately, it doesn't seem
> likely that this working group will reach consensus on such a
> recommendation.

Okay, how about:

Plan A: Try to sense whether we can agree on advice
Plan B: If we can't, just document the facts

Cheers,

---

From: KK Chittimaneni <[email-masked]>
Date: Sat, 27 Oct 2012 13:18:47 -0700

On Thu, Oct 25, 2012 at 6:53 PM, Lorenzo Colitti <[email-masked]> wrote:

> As always, the danger in trying to reach consensus on a controversial
> topic is that of endlessly discussing the issue, which makes it impossible
> to make a useful contribution to it. The way I see it, if we can't reach

+1

IMHO, it would be naive to ignore operational reality. It is better to
document the current state-of-affairs and let the rest of the community
make informed decisions based on this information.

---

From: Mark Smith <[email-masked]>
Date: Sun, 28 Oct 2012 13:08:31 -0700 (PDT)

Hi,

>________________________________
> From: Fernando Gont <[email-masked]>
>Cc: Mark Smith <[email-masked]>; V6 Ops <[email-masked]> 
>Sent: Friday, 26 October 2012 11:51 PM

I don't really disagree with that either, it's more that fragmentation is a

current capability of IPv6, so I think the IETF's recommendation should be
that it is enabled by default on the Internet. I think that recommendation
fits the robustness principle too - "..., be liberal in what you accept
from others".

If the IETF recommends against forwarding fragments, then I think that

creates the obligation to provide advice and methods on what do instead,
which might include specifying a standardised UDP fragmentation method,
and provide alternative methods for protocols that utilise IP layer
fragmentation.

Fragments may still be in use, however they may not used much at the

application layer. OSPFv2 and OSPFv3 uses them instead of implementing
it's own fragmentation mechanism (and that may be across multiple hops
in the case of a OSPF virtual link), and they are likely to be commonly
used in IPsec and GRE tunnels (PMTUD across the tunnel path and having
the tunnel MTU adjusted to it is a more advanced capability). My memory
is vague, however I also seem to remember seeing them being sent by load
balancers on the Internet too. At a residential ISP, this was no issue,
as we didn't perform any stateful firewalling at the edge of our network.

I think another thing to bare in mind is a lot of peoples' common approach

of taking a shortcut by just doing what the "experts" say. While
people like us might be interested in the details and pros and cons
of fragmentation, I think a lot of people just want the experts to say
"enable them" or "disable them", so they can move onto working on something
else on their list of things to do. If we don't provide that advice,
then people will default to what they believe is the safe position, and
their safe position is "if in doubt, switch it off". I think this is the
explanation as to why people have disabled all ICMPv4, breaking PMTUD -
they've heard that "ICMP is used by ping, and ping is bad security wise"
(i.e. the topology/host topology argument), so rather than investigating
the details, just universally disable ICMP. As they themselves rarely see
the consequences of PMTUD failing, they think what they've done is fine -
and give that advice to others if they're asked. That approach has propagated
to the point where MSS hacking on all subscribers is necessary in a broadband
scenario if you have a dumbell MTUs situation (i.e. PPPoE between cust LAN and
Internet)

>Plan B: If we can't, just document the facts

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Oct 2012 15:51:39 +0900

On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith <[email-masked]>wrote:

> I don't really disagree with that either, it's more that fragmentation is
> a current capability of IPv6, so I think the IETF's recommendation should
> be that it is enabled by default on the Internet. I think that
> recommendation fits the robustness principle too - "..., be liberal in what
> you accept from others".
>
> If the IETF recommends against forwarding fragments, then I think
> that creates the obligation to provide advice and methods on what do
> instead,
> which might include specifying a standardised UDP fragmentation
> method, and provide alternative methods for protocols that utilise IP layer
> fragmentation.
>
> application layer. OSPFv2 and OSPFv3 uses them instead of
> implementing it's own fragmentation mechanism (and that may be across
> multiple hops in the case of a OSPF virtual link), and they are likely to
> be commonly used in IPsec and GRE tunnels (PMTUD across the tunnel path and
> having the tunnel MTU adjusted to it is a more advanced capability).

Ok, so how about stating the following, then?

1. Fragments are unreliable on the Internet today.
2. If you're an application developer and your apps need to run on the
Internet, then fragments will likely not work in many cases. If you want
your application to work in these cases, you should either use
application-layer fragmentation, use path MTU discovery, or limit yourself
to small packets instead of sending fragments.
3. If you control the network (e.g., if you're the network operator), and
want to use fragments for tunnels or other purposes, go ahead, but note
that in other people's networks, they might be filtered.

Your suggestion of providing a generic UDP segmentation mechanism is a fine
idea, and one that we discussed before this draft was written, but our
feeling was that such a solution would be impossible to agree on until we
have a problem statement. This draft ("FYI: some operators filter
fragments. Keep that in mind.") was supposed to be the problem statement.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2012 07:57:14 +0000

On 29/10/2012 06:51, Lorenzo Colitti wrote:
...
> fragments. Keep that in mind.") was supposed to be the problem statement.

I think the real problem statement is "some operators filter some extension
headers, including fragments, and some operators filter ICMP PTB."

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Oct 2012 17:02:55 +0900

> headers, including fragments, and some operators filter ICMP PTB."

I think we can get to consensus as a group that filtering PTB is a bad idea
though, right?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2012 08:25:18 +0000

> I think we can get to consensus as a group that filtering PTB is a bad idea

I would hope so, and there's already an RFC that covers it, but you did suggest
PMTUD as an alternative to fragmentation. We'd better issue a *complete* advisory.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 29 Oct 2012 13:44:03 +0000

> PMTUD as an alternative to fragmentation. We'd better issue a *complete* advisory.

This, along with Lorenzo's other three points, could be that complete advisory? The same advisory can target different stakeholders.

Tim

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Oct 2012 08:08:58 -0700

How does that differ substantively from RFC 4821's advice? See esp. Sec. 
8 of that doc, which seems just as accurate for the current situation.

Joe

On 10/28/2012 11:51 PM, Lorenzo Colitti wrote:
> On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I don't really disagree with that either, it's more that
>     fragmentation is a current capability of IPv6, so I think the IETF's
>     recommendation should be that it is enabled by default on the
>     Internet. I think that recommendation fits the robustness principle
>     too - "..., be liberal in what you accept from others".
>
>     implementing it's own fragmentation mechanism (and that may be
>     across multiple hops in the case of a OSPF virtual link), and they
>     are likely to be commonly used in IPsec and GRE tunnels (PMTUD
>     across the tunnel path and having the tunnel MTU adjusted to it is a
>     more advanced capability).
>
>
> application-layer fragmentation, use path MTU discovery, or limit
> yourself to small packets instead of sending fragments.
> 3. If you control the network (e.g., if you're the network operator),
> and want to use fragments for tunnels or other purposes, go ahead, but
> note that in other people's networks, they might be filtered.
>
> Your suggestion of providing a generic UDP segmentation mechanism is a
> fine idea, and one that we discussed before this draft was written, but
> our feeling was that such a solution would be impossible to agree on
> until we have a problem statement. This draft ("FYI: some operators
> filter fragments. Keep that in mind.") was supposed to be the problem
> statement.
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 29 Oct 2012 08:50:21 -0700

Hi Lorenzo,

> Your suggestion of providing a generic UDP segmentation mechanism
> is a fine idea

This is exactly what SEAL does for tunnels:

In this model, the SEAL-enabled ingress tunnel endpoint acts as
an "application" that performs segmentation before encapsulation.

We have also talked about applying SEAL in a "transport" mode
of operation.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2012 16:18:57 +0000

> 8 of that doc, which seems just as accurate for the current situation.

Joe,

I have never thought that 4821 was specific enough, because it leaves
quite a bit of the recipe open. The application writer just wants to do
open/send/receive/close and have somebody else take care of this stuff.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Oct 2012 09:23:54 -0700

> open/send/receive/close and have somebody else take care of this stuff.

It has very specific advice in Section 8. I don't see much this WG can 
recommend beyond that until a few standards-track RFCs are revised, and 
that seems beyond the scope of this WG.

Joe

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Oct 2012 13:14:47 -0700 (PDT)

Hi Lorenzo,

> From: Lorenzo Colitti <[email-masked]>
>To: Mark Smith <[email-masked]> 
>Cc: Fernando Gont <[email-masked]>; V6 Ops <[email-masked]> 
>Sent: Monday, 29 October 2012 5:51 PM
>On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith <[email-masked]> wrote:
>
>I don't really disagree with that either, it's more that fragmentation is a current capability of IPv6, so I think the IETF's recommendation should be that it is enabled by default on the Internet. I think that recommendation fits the robustness principle too - "..., be liberal in what you accept from others".
>>
>>If the IETF recommends against forwarding fragments, then I think that creates the obligation to provide advice and methods on what do instead,
>>which might include specifying a standardised UDP fragmentation method, and provide alternative methods for protocols that utilise IP layer
>>fragmentation.
>>
>>application layer. OSPFv2 and OSPFv3 uses them instead of implementing it's own fragmentation mechanism (and that may be across multiple hops in the case of a OSPF virtual link), and they are likely to be commonly used in IPsec and GRE tunnels (PMTUD across the tunnel path and having the tunnel MTU adjusted to it is a more advanced capability).
>
>

That seems to be what the [blackhole] paper is concluding.

I haven't read the [blackhole] paper, although I've done a few text

searches of it. Thinking about this issue a bit more, I've started to
wonder how this fragmentation filtering is occurring in IPv6. Is it that
packets with the fragmentation extension header as the first extension
header are dropped, and all first extension header types are let through
(meaning a fragmentation extension header would pass as long as it isn't
the first), or is it that only TCP and UDP first extension headers are
let through (and perhaps IPsec ESP) and all others are dropped? My pure
guess would be the latter is more likely, meaning that this also breaks
DCCP and SCTP. I've been hoping that one of the benefits of IPv6 will be
the ability to use more modern transport layer protocols like DCCP and
SCTP without having to encapsulate them inside UDP.

>2. If you're an application developer and your apps need to run on the Internet, then fragments will likely not work in many cases. If you want your application to work in these cases, you should either use application-layer fragmentation, use path MTU discovery, or limit yourself to small packets instead of sending fragments.

ICMP based PMTUD is probably not reliable enough either :-(

>3. If you control the network (e.g., if you're the network operator), and want to use fragments for tunnels or other purposes, go ahead, but note that in other people's networks, they might be filtered.
>

That's ok for e.g. OSPF, however the use case I was thinking of for IPsec was across the Internet. It's about 10 years since I did a lot of work with IPsec tunnels so I'm wondering how they cope with varying MTUs, broken ICMP PMTUD etc. these days. I'm aware that IPsec has become commonly encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem to cover fragmentation issues below UDP.

>
>Your suggestion of providing a generic UDP segmentation mechanism is a fine idea, and one that we discussed before this draft was written, but our feeling was that such a solution would be impossible to agree on until we have a problem statement. This draft ("FYI: some operators filter fragments. Keep that in mind.") was supposed to be the problem statement.
>
>

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Oct 2012 13:35:38 -0700

Hi Mark,

> That's ok for e.g. OSPF, however the use case I was thinking of for IPsec
> was across the Internet. It's about 10 years since I did a lot of work
> with IPsec tunnels so I'm wondering how they cope with varying MTUs,
> broken ICMP PMTUD etc. these days. I'm aware that IPsec has become
> commonly encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem
> to cover fragmentation issues below UDP.

I haven't seen much talk about this, but IPsec tunnels should be
able to fragment IPv4 packets that enter the tunnel with DF=0,
since the IPsec integrity check will detect any IPv4 reassembly
errors. But, that's just for IPv4 DF=0 packets; IPv6 and IPv4 DF=1
packets are subject to PMTUD on entry of the tunnel the same as
for any link (unless they use SEAL, of course).

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Oct 2012 09:45:53 +0900

On Wed, Oct 31, 2012 at 5:14 AM, Mark Smith <[email-masked]>wrote:

> Is it that packets with the fragmentation extension header as the first
> extension header are dropped, and all first extension header types are let
> through (meaning a fragmentation extension header would pass as long as it
> isn't the first), or is it that only TCP and UDP first extension headers
> are let through (and perhaps IPsec ESP) and all others are dropped? My
> pure guess would be the latter is more likely, meaning that this also
> breaks DCCP and SCTP.

 I've been hoping that one of the benefits of IPv6 will be the ability to
> use more modern transport layer protocols like DCCP and SCTP without having
> to encapsulate them inside UDP.
>

I think DCCP and SCTP are easier than fragments.

I think there are two main issues here (in user/enterprise/edge networks;
not in backbone networks):

1. Allow through only what you use.
2. Allow through only what your hardware is capable of inspecting/filtering
at line rate.

#1 equally affects fragment headers and DCCP/SCTP/other protocols. However,
#2 specially affects fragment headers and other extension headers in
general.

As an example: a lot of hardware currently deployed, including, I believe,
the totality of one major backbone router vendor's product line, is unable
to inspect extension headers beyond the first - at all. On such hardware,
saying "allow SCTP from any port to port 53" is no different than saying
"allow UDP from this any port to port 53". The hardware has to do the same
number of lookups, and even the offsets are the same. It's a simple code
fix, if even that. However, saying "allow all UDP packets from any port to
port 53, including fragments" requires that the hardware be able to perform
a more complex lookup on the same packet - look for a fragment header, and
if it's there, skip over it to find the upper-layer protocol header. Things
get more expensive if you consider that it's not just fragment headers -
it's routing headers, and shim6 headers, and any $header that anyone can
dream up and get through the IETF.

Doing this at line rate is hard. AIUI many current forwarding architectures
work by hashing the first X (e.g., 128) bytes of the packet and turning it
into a lookup key that can be processed at high speed (e.g., in TCAM). On
such architectures, there is basically no way to process arbitrary
extension header chains at line rate without substantially increasing the
amount of work that the hardware has to do - and as we know, routers aren't
exactly cheap today.

If you allow the upper-layer header not to be in the first packet at all
(i.e., have the first fragment consist entirely of extension headers). In
this case, there is simply no way to filter correctly unless you do
full-blown stateful filtering AND ensure that all the packets are processed
by the same device.

> ICMP based PMTUD is probably not reliable enough either :-(

But it needs to be, or as others say, 1280 is the new 1500 and we'll never
get ourselves out of this hole. Fortunately I think it's easier than
processing arbitrary extension header chains.

> was across the Internet. It's about 10 years since I did a lot of work with
> IPsec tunnels so I'm wondering how they cope with varying MTUs, broken ICMP
> PMTUD etc. these days. I'm aware that IPsec has become commonly
> encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem to cover
> fragmentation issues below UDP.
>

As you say, I think we've given up on running IPsec across the Internet. We
use IPsec over UDP instead.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2012 08:18:23 +0000

On 31/10/2012 00:45, Lorenzo Colitti wrote:
...
> Fortunately I think it's easier than

Unfortunately the IPv6 architecture requires the network to
be transparent to arbitrary extension header chains.

This is beyond an operational problem, which is why it is
on the 6man agenda.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Oct 2012 17:49:59 +0900

> be transparent to arbitrary extension header chains.

Good luck with that in real networks.

---

From: [email-masked]
Date: Wed, 31 Oct 2012 12:21:10 +0100 (CET)

> Good luck with that in real networks.

Agreed. "Not gonna happen."

Steinar Haug, AS 2116

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2012 11:40:49 +0000

> Agreed. "Not gonna happen."

I am not totally unrealistic. However, there are some things that
the IETF can do to make the reality a bit better than it is at
the moment.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Oct 2012 21:51:39 +0900

> the IETF can do to make the reality a bit better than it is at

But why? If you can't get extension headers to work reliably in the
Internet (as opposed to in your own network), then what's the point? You
still need a fallback plan for when they get dropped, and users don't like
waiting. Why not just use the more reliable plan all the time?

---

From: Randy Bush <[email-masked]>
Date: Wed, 31 Oct 2012 23:25:16 +0900

>> Fortunately I think it's easier than processing arbitrary extension
>> header chains.

it is cheering to see that the ipv6 ivory tower still stands despite
years of attack by reality.

> This is beyond an operational problem, which is why it is

and how much of good people's time do you plan to waste on this
windmill, don?

rosenantes

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 31 Oct 2012 14:47:57 +0000

> and how much of good people's time do you plan to waste on this

Randy,

you're right that we appear to have backed ourselves into a corner where we
expect kit to be able to handle TLV processing at wire speed.

Rather than stowing thrones, do you have any constructive suggestions on
how to deal with the situation?

Nick

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Nov 2012 00:04:21 +0900

> you're right that we appear to have backed ourselves into a corner
> where we expect kit to be able to handle TLV processing at wire speed.

nous?

but little sense going through the whole discussion why vendor support
for v6 with headers, long masks, ... at wire speed will be another
couple of spins away.  it will come, but too late to save the overly
complex architectural decision.  but blame don't move packets.

> Rather than stowing thrones, do you have any constructive suggestions
> on how to deal with the situation?

we have seen the mtu discussions for decades.  no pixie dust.  all we
have ever come up with is big warning signs and pleas for pmtud.

rosenantes

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Nov 2012 00:21:18 +0900

> how to deal with the situation?

How about deprecate fragmentation at the IP layer and standardize a
higher-layer alternative?

IPv6 extension headers were standardized in 1995. I'd argue that in 1995
nobody could have foreseen hardware forwarding and that we'd have routers
capable of pushing tens of terabits per second. And while other aspects of
IPv6 were designed to reduce load on routers,. unfortunately, extension
headers were not. Because routers *do* inspect packet contents - for
security, QoS classification, accounting, and a thousand other
reasons. From the point of view of reducing load on routers, extension
headers were a mistake.

Yes, it's possible to put arbitrary length TLV processing in silicon so it
can forward at line rate packets with 8 extension headers - but we're not
suggesting that router vendors do that, are we? Because silicon is
expensive. And if that's not what we are suggesting, then what is it that
we really want? Up to one extension header? Up to two?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 Oct 2012 08:43:20 -0700

> How about deprecate fragmentation at the IP layer

Why? So that routers in the middle of the network can more
quickly do something that they shouldn't be doing in the
first place?

> and standardize a higher-layer alternative?

For that, we have SEAL. RFC5320 is an experimental earlier
version that specifies both tunnel and transport modes of
operation. SEAL(bis) ('draft-templin-intarea-seal') currently
only specifies tunnel mode operation, but we can bring back
transport mode if there is sufficient interest. It is currently
in the RFC Editor queue as an Informational submission, but
maybe we should reclassify it as standards track?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 Oct 2012 08:45:07 -0700

> have ever come up with is big warning signs and pleas for pmtud.

You forgot about SEAL.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2012 17:27:34 +0000

> waiting. Why not just use the more reliable plan all the time?

For MTU/fragmentation issues, there may be such a plan.

There are other extension headers for which there is no such plan.

Come to 6man.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Oct 2012 15:54:00 -0200

> There are other extension headers for which there is no such plan.

The end-result is/is going to be that sine extension headers are not
reliable, no mechanism will be able to rely on them. SO, in practice,
you better put your "options"/fragmentation somewhere else, or prepare
to be dropped.

It happened with IPv4 options already....

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Oct 2012 11:11:14 -0700

> It happened with IPv4 options already....

Yes, but the whole point of the IPv6 option architecture was to avoid 
the issues seen with IPv4 options.

Consider that:

	- routers don't like fragments because they can't inspect them

	- so we tunnel and fragment in a higher level protocol

		the router now needs to implement the higher protocol
		and still fragment or else we cannot have tunnels

		the routers on the path still cannot inspect the
		higher-level fragments

So we're back to the reason this all breaks - routers doing something 
that we simply cannot support in the architecture.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Oct 2012 16:34:09 -0200

> the issues seen with IPv4 options.

The only thing in that IPv6 would avoid is requiring routers to parse
*all* options, just to find the ones that need to be processed by routers.

While the IPv6 extension header syntax is good in terms of extensibility
(in principle, you can include as many options as you want9, it also
allows for pathological cases in which the header chain is split among
multiple fragments (we're working on fixing that one), and also requires
any box that wants to find the upper-layer header to parse the entire
IPv6 header chain -- something that a large number of devices cannot do
at wire speed.

For filtering purposes, it'd been interesting to have a pointer to the
upper-layer header -- although with the original specs, it might simply
not be there. With IPv4, at the very least it's trivial to find the
upper layer protocol: just skip the first IHL of the packet, and you're
there. With IPv6, at leasts in theory, it might be impossible (unless
you reassemble-filter-and-refragment).

> that we simply cannot support in the architecture.

It's probably time to accept that firewalls and routers implementing
ACLs are part of the architecture. One might argue that the use of
firewalls couldn't be foreseen with IPv4. But at the time IPv6 was
designed, it was already a reality.

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Oct 2012 11:58:57 -0700

> *all* options, just to find the ones that need to be processed by routers.

Yes.

However, since fragmentation is near the end of the set of possible 
options, that means that ANY recommendations about how IPv6 routers 
handle options will require deep option parsing. How does that help?

> (in principle, you can include as many options as you want, it also

I thought we were talking more about fragmentation - which defeats 
filtering on upper layer info anyway.

The non-HBH options can be split across fragments, but not the HBH ones.

> you reassemble-filter-and-refragment).

In both cases fragmentation defeats DPI. But then so does IPsec.

Yes, IPv6's chained header structure is not DPI-friendly. But this isn't 
news, is it?

> ACLs are part of the architecture.

We need to accept one of three things:

	DPI is part of the architecture
		either don't use IPv6 options
		or don't use IPv6

	IPv6 options are part of the architecture
		DPI isn't meaningful anymore

 > One might argue that the use of

So that means IPv6 was designed to inhibit the use of options, or 
designed to inhibit its own deployment.

Seems like the latter is coming to fruition.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Oct 2012 17:51:47 -0200

> handle options will require deep option parsing. How does that help?

mm.. not sure what you mean. Could you elaborate a bit more?

> filtering on upper layer info anyway.

It *currently* does in v6, but not in v4: in v4 the first fragment
always has, at the very least, the IP addresses, upper-layer protocol,
and transport ports. In v6 (with the current specs), that might not be
the case.

> The non-HBH options can be split across fragments, but not the HBH ones.

And...?

> In both cases fragmentation defeats DPI. 

Please see above (the situation in v6 is different from the v4 one9.

>         either don't use IPv6 options

I'd put it as "DPI is part of the architecture. Beware that IPv6 packets
carrying options are not reliable. Use them at your own risk.".

> Seems like the latter is coming to fruition.

I'd argue that the problems with v6 deployment have more to do with
what's noted in RFC 1669 than with DPI. But that train has already left.
So we better try to improve v6 to the best of our possibilities, where
necessary.

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Oct 2012 13:00:09 -0700

> mm.. not sure what you mean. Could you elaborate a bit more?

The fragment header is not required to be the first header; it's 
required to come after the HBH and before the E2E ones.

So "must drop IPv6 fragments" implies parsing ALL HBH headers that come 
before the frag header (or you'd never know the frag header was there).
>> The non-HBH options can be split across fragments, but not the HBH ones.

I'm not sure what bug you're implying above ("we're working on fixing 
that one"), but it's not that the entire chain is split among the fragments.

Joe

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2012 13:03:48 -0700 (PDT)

Hi,

>To: Brian E Carpenter <[email-masked]> 
>Cc: [email-masked]; [email-masked] 
>Sent: Wednesday, 31 October 2012 11:51 PM
>On Wed, Oct 31, 2012 at 8:40 PM, Brian E Carpenter <[email-masked]> wrote:
>
>But why? If you can't get extension headers to work reliably in the Internet (as opposed to in your own network), then what's the point? You still need a fallback plan for when they get dropped, and users don't like waiting. Why not just use the more reliable plan all the time?
>_

So I think, using the "dumb network, smart hosts" model, these measures

(dropping fragments, dropping extension headers, and dropping ICMP) are
making the Internet dumber, and that means the hosts will need to become
smarter. Smarter hosts will either choose to use the simple base capability
of the network (e.g. 1280 MTU), or need to measure the availability of the
features they want to use (PMTUD), without relying on the the network to
indicate which features are and are not currently available (ie. ICMP PTB).

There are already examples of hosts doing this active measuring - packet
loss indicating to TCP that congestion is occurring, measuring PMTU without
relying on ICMP (RFC4821), NAT presence determination using STUN.

Before and unrelated to this thread, I've recently been thinking about

what the impact of the rapid adoption of wireless, mobile multihomed hosts
(a.k.a. smartphones and tables) will be to enterprise and carrier networks,
and what would happen to network QoS and network located security if these
hosts started using Multipath TCP. As these hosts' point of attachment
will never be consistent, and even the performance of the links they're
commonly attached can change over time (i.e. wifi), they'll never be able
to assume a consistent network layer service (throughput, MTU, extension
header support etc., NAT presence, IPv4 and/or IPv6), and therefore will
need to actively measure it if they want to utilise more than just the base
functionality. They'll also need to be responsible for their own security.

The Happy eyeballs technique is another example of a host dynamically
coping with the availability or unreliability of a feature it wants to use.

So perhaps the topic of this draft needs to be encompassed into something

larger, discussing the "dumbing down" of the Internet, and what hosts,
both fixed and rapidly growing numbers of multihomed mobile ones, need to
do to cope when the only reliable indicator from the network layer that
something has gone wrong is packet loss, and that there is no reliable
indicator of what went wrong.

______________________________________________

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2012 13:12:57 -0700 (PDT)

\> 
> (a.k.a. smartphones and tables) 

That should be "tablets". Rapid adoption of mobile tables will make my train ride to work much more uncomfortable.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 31 Oct 2012 20:33:31 +0000

> the size of the packets they send down to 1280.

They are also an obvious place to use a subnetwork-dependent protocol. RFC 1990, for example, builds a segment/reassembly protocol that runs atop a (set of) PPP link(s). If the advice of the operators is that they would like the fragment header to go away, which is the net effect of fragdrop, one could imagine a tunneling protocol that was in essence GRE plus a fragmentation field (packet id plus sequence number), intended to be exchanged by tunnel/encapsulation endpoints.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 Oct 2012 13:47:17 -0700

Hi Fred,

> one could imagine a tunneling protocol that was in essence GRE plus a
> fragmentation field (packet id plus sequence number), intended to be
> exchanged by tunnel/encapsulation endpoints.

SEAL can be used either along with or instead of GRE, based
on the use case. SEAL has the fragmentation field you've
mentioned which is used to accommodate "medium-sized" packets
(between 1280-1500) but it also holds the gate open for smaller
and larger packets to go through. The SEAL MTU philosophy is:

"Take care of the smalls and let the bigs take care of themselves"

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Oct 2012 13:56:30 -0700

Hi, all,

As per my recent post, the claim that "we cannot parse the entire IP 
option chain at line rate" doesn't fit with "so we should drop IP 
fragments", since the fragment option need not appear at the head of the 
option chain.

I'm wondering whether routers that drop fragments do so only when that's 
the first option, or do they just drop packets with *any* options?

If just fragments, a quick fix might be to create a new null HBH option 
that is silently ignored, solely to bury the fragment option away from 
the primary IPv6 next-header field.

Can anyone with such a router comment as to what might happen?

Thanks,

Joe

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Nov 2012 09:35:07 +0900

> the first option, or do they just drop packets with *any* options?

Routers just do what operators configure them to do.

Operators who want to have their routers do things like:

- Attack (e.g., SYN flood) rate-limiting
- Stateless ACL processing for security purposes
- QoS classification
- ... and so on

configure their routers to look at upper-layer headers. If the routers
cannot parse the extension header chain but only look at the next header
value in the IPv6 header, then the operators have a choice:

1. Give up the above functionality.
2. Drop all packets with extension headers.

It's not just the fragment header, it's all extension headers. The fragment
header is just the most important one.

In general: I'm not an expert, but I think the situation where processing
an IPv6 packet may require 8 or 10 lookups, arbitrarily spaced within a
1500-byte packet, is not easy to implement in hardware. It doesn't work on
today's architectures, and I suspect supporting it might increase the cost
of forwarding hardware

Supporting extension header chain parsing at anything other than wire speed
exposes operators to a resource exhaustion attacks where attackers can
increase load on routers (e.g., force packets to be software switched)
simply by sending legitimate packets with lots of extension headers. So
really it's not practical to say that you can simply provision / build for
partial load since "packets with lots of extension headers are rare".

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Oct 2012 17:51:19 -0700

On 10/31/2012 5:35 PM, Lorenzo Colitti wrote:
> On Thu, Nov 1, 2012 at 5:56 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I'm wondering whether routers that drop fragments do so only when
>     that's the first option, or do they just drop packets with *any*
>     options?
>
>

Not everything; as you note below, some aspects of the configuration are 
limited by capability.

However, you've answered the key issue - this is not about fragments, 
but rather about two things:

a) DPI
	DPI cannot be done on packets with any options
	so this either means operators need to ignore DPI
	on such packets or drop them

There are certainly places where DPI is expected (e.g., by a 
government), and so only DPI-capable packets are permitted, but this 
doesn't seem tenable anywhere except at the boundaries of customer 
networks (otherwise all encrypted traffic would be dropped all over the 
place, and that doesn't appear to be happening)

b) support for ANY HBH options
	unfortunately, this is very difficult to determine
	unless fragmentation or a known destination option occurs

I.e., there's no structure to the option numbers that makes it easy to 
say "there are no more HBH options", so the best that can be done here 
is, as you note, "drop all packets with any options".

Again, however, that doesn't necessarily mean all remaining packets can 
be DPI processed.

Joe

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Nov 2012 09:58:48 +0900

On Thu, Nov 1, 2012 at 9:51 AM, Joe Touch <[email-masked]> wrote:

> However, you've answered the key issue - this is not about fragments, but
> rather about two things:
>
> a) DPI

I don't think we should use the term DPI, because we don't really have
consensus on what it means. I suspect some would assert that just looking
at layer 4 headers is not DPI and that it's only DPI if you look into layer
4 payloads as well.

> There are certainly places where DPI is expected (e.g., by a government),
> and so only DPI-capable packets are permitted, but this doesn't seem
> tenable anywhere except at the boundaries of customer networks (otherwise
> all encrypted traffic would be dropped all over the place, and that doesn't
> appear to be happening)
>

... and saying that looking at layer 4 headers is "DPI" will also lead to
this kind of confusion.