Subject: Re: UDP+Fragmentation (was: "Deprecate")

From: RJ Atkinson <[email-masked]>
Date: Thu, 1 Aug 2013 10:45:30 -0400

I agree that C.M. Heard's ideas should be explored
in more detail by the IETF.  

(I defer to the Powers That Be which list that might
belong to -- TSV WG list might be one option, but
it is not as likely to have IPv6 operators as well
represented as the IPv6 list seems to have.)

Yours,

Ran

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 1 Aug 2013 10:11:52 -0700 (PDT)

> in more detail by the IETF.  

Not just my suggestion, but other ideas as well:

- put UDP source and destination ports in a new IPv6 option that and 
  add it along with a fragment header when fragmenting UDP packets 
  (suggested on-list by Mark Andrews).

- generic transport encapsulation within UDP (suggested to me
  off-list by Mark Smith, based on a draft by Stuart Cheshire 
  et. al.).

- SEAL (suggested on-list by Fred Templin)

> represented as the IPv6 list seems to have.)

That's really important -- it doesn't do anyone any good to have a 
theoretical solution that operators are not willing to deploy.  We 
all need to work together here.

Thanks,

Mike Heard

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 1 Aug 2013 21:55:23 -0700 (PDT)

Hi,

----- Original Message -----
> From: C. M. Heard <[email-masked]>
> To: IPv6 <[email-masked]>
> Cc: 
> Sent: Friday, 2 August 2013 3:11 AM
> Subject: Re: UDP+Fragmentation (was: "Deprecate")
> 

For those on the list, the draft I mentioned was :

Encapsulation of TCP and other Transport Protocols over UDP
http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00

Note that this basically proposes translating the TCP header into UDP header fields, and then for the missing fields, appending them after the UDP header. I was a bit confused by what was proposed, until I thought about a web server specifically listening on UDP port 80, knowing that UDP port 80 is TCP over UDP, and then decoding the UDP fields and subsequent fields as a TCP header.

> all need to work together here.

Actually, it has occurred to me that there are two fragmentation related problems, rather than one:

(1) fragmentation doesn't work reliably

(2) fragments can hide transport layer protocol ports, preventing simple ACL filtering etc.

The reaction to (2) of dropping fragments causes (1).

A general solution like SEAL (which I think in the big picture would be better), probably doesn't solve (2) (I assume, I've had nothing more than a brief look), so the people who care about (2) won't find SEAL or similar addresses their problem.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 1 Aug 2013 23:12:28 -0700 (PDT)

----- Original Message -----
> From: Mark ZZZ Smith <[email-masked]>
> To: C. M. Heard <[email-masked]>; IPv6 <[email-masked]>
> Cc: 
> Sent: Friday, 2 August 2013 2:55 PM
<snip>
> Note that this basically proposes translating the TCP header into UDP header 
> fields, and then for the missing fields, appending them after the UDP header. I 
> was a bit confused by what was proposed, until I thought about a web server 
> specifically listening on UDP port 80, knowing that UDP port 80 is TCP over UDP, 
> and then decoding the UDP fields and subsequent fields as a TCP header.
> 
> 

And actually to better clarify, my (quick) suggestion was to put fragmentation fields after the UDP header, similar to how that draft places the TCP fields after the UDP header.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Aug 2013 10:50:57 +1200

> And actually to better clarify, my (quick) suggestion was to put fragmentation fields after the UDP header, similar to how that draft places the TCP fields after the UDP header.

May I make a plea for any such proposal to be carefully evaluated against
common practices in stateful firewalls and load balancers. I'm rather concerned
that the problems these middleboxes create with conventional fragmentation
will soon come back with UDP-encapsulated fragmentation. (There is no problem
in computer science that can't be made harder by recursion.)

    Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 3 Aug 2013 09:20:51 -0700 (PDT)

On Sat, 3 Aug 2013, Brian E Carpenter wrote:
> > [ Mark ZZZ Smith wrote ]
...
> > > [ C. M. Heard wrote ]
...
> > > >     off-list by Mark Smith, based on a draft by Stuart Cheshire 
...
> in computer science that can't be made harder by recursion.)

Yes, UDP-encapsulated fragmentation (in its simplest form) has 
exactly the same issue as conventional IP fragmentation -- it hides 
the actual L4 header information in all but the first fragment.  
Operators who filter conventional IP fragments would have exactly 
the same motivation to filter UDP-encapsulated fragments.

> simple ACL filtering etc.
...
> A general solution like SEAL (which I think in the big picture 
> would be better), probably doesn't solve (2)

SEAL transport mode, as currently proposed, addresses the problem by 
including port numbers in all non-initial segments:.  See:

https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32

Mike Heard

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Aug 2013 17:09:10 +0000

Hi Mike,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> C. M. Heard
> Sent: Saturday, August 03, 2013 9:21 AM
> To: IPv6
> Subject: Re: UDP+Fragmentation
> 

Thanks for pointing this out. Another problem I have heard is that
initial fragments are sometimes so small that the L4 information
does not fit, or that non-initial fragments may sometimes "overlap"
the initial fragment and invalidate any filtering checks that were
applied to the initial fragment. SEAL addresses this by requiring
that the initial fragment be at least 256 bytes in length and that
all fragments except the final one contain an integer multiple of
256 byte blocks. Overlapping fragments are also explicitly forbidden.

Thanks - Fred
[email-masked]

> Mike Heard
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Aug 2013 11:41:22 +1000

In message <[email-masked]
> [email-masked]

SEAL however doesn't appear to be incrementally deployable.  You need
the destination to be SEAL aware as it is a destination header not a
destination option.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Aug 2013 11:54:58 +1000

> SEAL however doesn't appear to be incrementally deployable.  You need

	s/incrementally/opportunistically/

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 5 Aug 2013 20:12:40 -0700 (PDT)

> the destination to be SEAL aware as it is a destination header not a

Except for the hop-by-hop option proposal in

http://tools.ietf.org/id/draft-andrews-6man-fragopt

all of the proposals informally floated so far suffer from that 
disadvantage.  That includes a new version of UDP with segmentation, 
generic transport encapsulation within UDP, and SEAL.

As mentioned elsewhere, generic transport encapsulation within UDP 
does not really address the problem, as it lacks L4 header 
information in all fragments except the first (see 
http://www.ietf.org/mail-archive/web/ipv6/current/msg18687.html).

The hop-by-hop option proposal and SEAL suffer from a security hole: 
the L4 information is duplicated, and thereby creating a security 
hole.  An attacker could put one thing in the option or in the SEAL 
header (to be interpreted by a middlebox) and another thing in the 
actual transport header (to be interpreted by an end system).  A new 
version of UDP would not have this problem, as the same header would 
be interpreted by both the middlebox and the end system.

The hop-by-hop option proposal suffers from another problem. Quoting 
from http://tools.ietf.org/id/draft-ietf-6man-ext-transmit-02.txt 
Section 2.2:

   It is to be expected that high performance routers will either 
   ignore it, or assign packets containing it to a slow processing 
   path.  Designers planning to use a Hop-by-Hop option need to be 
   aware of this likely behaviour.

The problem in the present case arises if high performance routers 
put packets with hop-by-hop options on a slow path.

//cmh

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Aug 2013 13:34:51 +1000

> be interpreted by both the middlebox and the end system.

Actually draft-andrews-6man-fragopt doesn't as the option is in all
fragments and policy devices can decide whether to pass mis-matching
initial fragments or not.  I don't see policy devices passing
non-initial fragments where you can't do this check.

A filter rule like "pass dstport 80 srcport any" would enforce that
destination ports matched but wouldn't care that the source ports
didn't.

> put packets with hop-by-hop options on a slow path.

Well properly design your router.  It is a design choice to slow
path hop-by-hop processing.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 5 Aug 2013 20:53:23 -0700 (PDT)

> > in more detail by the IETF.

The idea was essentially UDP with segmentation fields, which would 
require a new protocol number.

In an offline discussion with Mark Smith and I kicked around an idea 
for an alternate version not requiring a new protocol number, but 
relying instead on the redundancy of the UDP Length field.  The UDP 
Length field is not actually needed; TCP does not have one but 
rather relies on the length reported by the IP layer.  Under current 
standards, the UDP Length field must be at least 8 and cannot exceed 
the IP payload length minus the combined length of any extension 
headers -- let's call this the L4 length from IP.  Existing 
implementations are supposed to drop UDP datagrams that fail this 
check, and all the ones I know of do so.

The question then arises whether it might reasonably be possible to 
re-purpose the case UDP Length > L4 length from IP to mean a 
segmented UDP datagram.

In that case 8 <= UDP Length <= L4 length from IP would be 
intepreted as a standard unsegmented UDP datagram, as is it now.  
That's the case pictured below.  Note that if the L4 length 
indicated by the IP layer exceeds the UDP Length, then the extra 
octets would be discarded and are not delivered to the application; 
that is the behavior of the implementations I know of.

     0                            15 16                            31
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |         Source Port           |      Destination Port         |
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |   Length <= L4 length from IP |            Checksum           |
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |                          data octets               ...
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    ...

Now suppose that we have a long UDP datagram that we want to send in 
segments.  We set the Length and Checksum fields as usual, and then 
cut the datagram into segments, each of which looks like this:

     0                            15 16                            31
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |         Source Port           |      Destination Port         |
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |  Length > L4 length from IP   |            Checksum           |
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |        (reserved = 0)         |       Segment Offset    |Res|M|
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |                         Identification                        |
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
    |                          data octets               ...
    +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    ...

We put the same UDP header in each segment, so (if we take some care 
in how we choose the length of the segments) each one will have a 
UDP Length field that is greater than the IP payload length minus 
the combined length of any extension headers.  Implementations that 
conform to the current specifications should discard these segments, 
and so should not mistakenly consider the segmentation fields as 
part of the application data.  That should make it possible for 
segmented UDP datagrams to safely coexist with conventional 
unsegmented one, without getting a new protocol number.

Possible downsides: some middleboxes may filter such "erroneous" 
datagrams, and some existing erroneous implementations may fail to 
do the checks they should and might mistake these segments for 
ordinary UDP datagrams.

Note that this idea does not work with UDP-lite, which replaces the 
Length field with a Checksum Coverage field.  That could easily be 
too short to exceed the L4 length from IP.

Mike Heard

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 14:25:07 +0000

Hi Mike,

> be interpreted by both the middlebox and the end system.

For SEAL, that is a bug in the spec which is easily fixed. What
it should say is that the initial segment does not carry the L4
information from the transport layer protocol so the middlebox
interprets only based on the actual transport header. It is only
in non-initial segment that the transport layer information needs
to appear in the header. I'll fix that.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 15:02:48 +0000

Hi,

In these discussions, it seems like we might be losing sight
of what problem or problems we are trying to address. The focus
of the non-SEAL proposals seems to be solely on making L4 port
information available in non-initial fragments. Important yes,
but there are other problems that need to be addressed.

For example, for the tiny fragment attack SEAL mandates that
the initial fragment be at least 256 bytes in length such that
a tiny fragment attack is not physically possible. Non initial
fragments are also physically constrained such that they cannot
begin before the 256th byte, so an overlapping fragment that
corrupts the transport layer headers is not possible. SEAL also
provides a path MTU probing facility to determine when the path
MTU is large enough to suspend the segmentation and reassembly
process. SEAL also works in the absence of ICMP Packet Too Big
messages. It also provides a tunnel-mode as well as transport-mode
of operation, and supports all combinations of IPv6/IPv4 tunneling
(6-in-6, 4-in-6, 6-in-4, 4-in-4). And, SEAL is also a universal
encapsulation framework that works with any existing transport
layer protocol that needs to use it.

So, there are lots of issues to be addressed - not just one.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 6 Aug 2013 18:49:11 +0000

Mike,

The proposal sounds elegant. I will try to paraphrase it to make sure that I understand.

When originating a UDP datagram, the host always queries it underlying IP stack to determine the PMTU for the destination. If the PMTU greater than or equal to the size of the payload plus the UDP header plus the IP header, plus all IP extension headers, the originating host emits a conventional UDP packet which is characterized as follows:

- Protocol = 17
- Length <= L4 length from IP

If the PMTU less than the size of the payload plus the UDP header plus the IP header, plus all IP extension headers, the originating host emits an unconventional UDP packet which is characterized as follows:

- Protocol = 17
- Length > L4 length from IP
- Segment Offset, M-bit and Identification fields added to UDP header before the payload

If an unconventional UDP packet arrives a destination that supports unconventional packets, it is reassembled at the transport layer. If an unconventional UDP packet arrives a destination that does not support unconventional packets, it is  discarded.

Do I have this much right?

                          Ron

> Sent: Monday, August 05, 2013 11:53 PM
> To: IPv6
> > > I agree that C.M. Heard's ideas should be explored in more detail
> by
> > > the IETF.
> 
> Length field is not actually needed; TCP does not have one but rather
> relies on the length reported by the IP layer.  Under current
> The question then arises whether it might reasonably be possible to re-
> purpose the case UDP Length > L4 length from IP to mean a segmented UDP
> datagram.
> 
> In that case 8 <= UDP Length <= L4 length from IP would be intepreted
> as a standard unsegmented UDP datagram, as is it now.
> That's the case pictured below.  Note that if the L4 length indicated
> by the IP layer exceeds the UDP Length, then the extra octets would be
> discarded and are not delivered to the application; that is the
> behavior of the implementations I know of.
> 
>      0                            15 16                            31
> segments.  We set the Length and Checksum fields as usual, and then cut
> the datagram into segments, each of which looks like this:
> 
>      0                            15 16                            31
> We put the same UDP header in each segment, so (if we take some care in
> how we choose the length of the segments) each one will have a UDP
> Length field that is greater than the IP payload length minus the
> combined length of any extension headers.  Implementations that conform
> to the current specifications should discard these segments, and so
> should not mistakenly consider the segmentation fields as part of the
> application data.  That should make it possible for segmented UDP
> datagrams to safely coexist with conventional unsegmented one, without
> getting a new protocol number.
> 
> datagrams, and some existing erroneous implementations may fail to do
> the checks they should and might mistake these segments for ordinary
> UDP datagrams.
> 
> Length field with a Checksum Coverage field.  That could easily be too
> short to exceed the L4 length from IP.
> 
> Mike Heard

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 18:57:40 +0000

With a protocol as ossified as UDP, I have a hard time imagining
all middleboxes passing the packets with what they would see as
a corrupted length field.

Thanks - Fred

> Ronald Bonica
> Sent: Tuesday, August 06, 2013 11:49 AM
> To: C. M. Heard; IPv6
> Subject: RE: UDP+Fragmentation (was: "Deprecate")
> 
> Mike,
> 
> When originating a UDP datagram, the host always queries it underlying
> IP stack to determine the PMTU for the destination. If the PMTU greater
> than or equal to the size of the payload plus the UDP header plus the
> IP header, plus all IP extension headers, the originating host emits a
> conventional UDP packet which is characterized as follows:
> 
> - Protocol = 17
> If the PMTU less than the size of the payload plus the UDP header plus
> the IP header, plus all IP extension headers, the originating host
> emits an unconventional UDP packet which is characterized as follows:
> 
> - Protocol = 17
> If an unconventional UDP packet arrives a destination that supports
> unconventional packets, it is reassembled at the transport layer. If an
> unconventional UDP packet arrives a destination that does not support
> unconventional packets, it is  discarded.
> 
> re-
> cut
> in

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 6 Aug 2013 21:53:42 +0000

Fred,

If that's the case, we have a good argument for changing Mike's proposal ever so slightly, so that it uses a new protocol ID. But still, Mike's proposal is elegant because:

a) It solves the problem at the right layer
b) It reuses UDP transport machinery. (The only exception is the in LENGTH field)
c) It reuses IP fragmentation machinery (moving it to the transport layer)
d) Aside from b) and c), it introduces no new protocol machinery. So, it can be described in a few short pages. This is in stark contrast to SEAL (draft-templin-intarea-seal-61) whose protocol machinery requires 41 pages to describe which required 61 draft versions to get right.

                                                 Ron

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2013 2:58 PM
> To: Ronald Bonica; C. M. Heard; IPv6
> With a protocol as ossified as UDP, I have a hard time imagining all
> middleboxes passing the packets with what they would see as a corrupted
> length field.
> 
> Thanks - Fred
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Ronald Bonica
> > IP stack to determine the PMTU for the destination. If the PMTU
> > greater than or equal to the size of the payload plus the UDP header
> > plus the IP header, plus all IP extension headers, the originating
> > host emits a conventional UDP packet which is characterized as
> follows:
> >
> > - Protocol = 17
> > unconventional packets, it is reassembled at the transport layer. If
> > an unconventional UDP packet arrives a destination that does not
> > support unconventional packets, it is  discarded.
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > C. M. Heard
> > > octets would
> > be
> > >      0                            15 16
> 31
> > >      0                            15 16
> 31
> > >     |                         Identification
> |
> > > should not mistakenly consider the segmentation fields as part of
> > > the application data.  That should make it possible for segmented
> > > UDP datagrams to safely coexist with conventional unsegmented one,
> > without
> > > IETF IPv6 working group mailing list [email-masked] Administrative
> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 22:07:09 +0000

Hi Ron,

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2013 2:54 PM
> To: Templin, Fred L; C. M. Heard; IPv6
> If that's the case, we have a good argument for changing Mike's
> proposal ever so slightly, so that it uses a new protocol ID. But
> still, Mike's proposal is elegant because:
> 
> d) Aside from b) and c), it introduces no new protocol machinery. So,
> it can be described in a few short pages. This is in stark contrast to
> SEAL (draft-templin-intarea-seal-61) whose protocol machinery requires
> 41 pages to describe

There is a lot of boiler plate in the draft that is not required to
describe the protocol machinery. Plus, there are many things that
need to be described in a functional specification beyond just
posting a concept in an e-mail thread.

> which required 61 draft versions to get right.

The best things in life are worth investing the time and energy
to get right. Plus, SEAL is a universal format that handles both
tunnel- and transport-mode requirements for all manners of
existing protocols.

If we are going to define a new protocol type, let's define one
that addresses everything we are currently struggling with and
has the extensibility to address additional requirements moving
forward into the future.

Thanks - Fred

> > > The proposal sounds elegant. I will try to paraphrase it to make
> sure
> > > that I understand.
> > >
> > > - Segment Offset, M-bit and Identification fields added to UDP
> header
> > > before the payload
> > >
> > > > purpose the case UDP Length > L4 length from IP to mean a
> segmented
> > > UDP
> > > > datagram.
> > > >
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     |                          data octets               ...
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     |                         Identification
> > |
> > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-
> +-
> > +-+
> > > >     |                          data octets               ...
> > > > -----------------------------------------------------------------
> --
> > -
> > > > -----------------------------------------------------------------
> --
> > -
> > > >
> > >
> > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 22:35:45 +0000

Ron,

One other thing for now is that Mike's proposal doesn't even
address the attack vector that 'draft-bonica-6man-frag-deprecate'
is concerned about. To address the tiny fragment concern, the
protocol must ensure that tiny fragments cannot ever be created.

Thanks - Fred

> Templin, Fred L
> Sent: Tuesday, August 06, 2013 3:07 PM
> all
> > > > > The question then arises whether it might reasonably be
> possible
> > to
> > > > re-
> > > > > Now suppose that we have a long UDP datagram that we want to
> send
> > > in
> > > > > to the current specifications should discard these segments,
> and
> > so
> > > > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Doug Barton <[email-masked]>
Date: Tue, 06 Aug 2013 15:39:42 -0700

> has the extensibility to address additional requirements moving

So in other words let's make all the same mistakes we made with the 
design of IPv6?  :)

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 22:41:56 +0000

> So in other words let's make all the same mistakes we made with the

Not even. This is about fixing and atoning for mistakes; not
introducing new ones.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 7 Aug 2013 01:45:32 +0000

Fred,

We should probably be clear about which problem we are trying to solve. The following are possibilities:

a) Remove network administrators' motivation for blocking IPv6 fragments. To this end, we assume that the network administrators' primary motivation is the tiny fragment problem. So, we solve the tiny fragment problem by changing the way that IPv6 fragmentation works. In the new fragmentation scheme, each fragment contains parsable information regarding the payload protocol and port.

b) Make UDP-based applications work in a world where network administrators block IPv6 fragments. We do this by either modifying UDP so that it supports fragmentation and reassembly of long payloads or creating a new UDP-like protocol that supports the fragmentation and reassembly of long payloads.

Draft-andrews-6man-fragopt solves the problem posed in draft-bonica-6man-frag-deprecate by solving problem a). Mike's proposal solves the problem posed in draft-bonica-6man-frag-deprecate by solving problem a).

IMHO, both proposals address the problem. We are currently trying to figure out which will work best.

                                                      Ron

> Sent: Tuesday, August 06, 2013 6:36 PM
> One other thing for now is that Mike's proposal doesn't even address
> the attack vector that 'draft-bonica-6man-frag-deprecate'
> is concerned about. To address the tiny fragment concern, the protocol
> must ensure that tiny fragments cannot ever be created.
> 
> Thanks - Fred
> > Of Templin, Fred L
> > > d) Aside from b) and c), it introduces no new protocol machinery.
> > > So, it can be described in a few short pages. This is in stark
> > > contrast
> > to
> need
> > to be described in a functional specification beyond just posting a
> > concept in an e-mail thread.
> >
> > The best things in life are worth investing the time and energy to
> get
> > right. Plus, SEAL is a universal format that handles both
> > tunnel- and transport-mode requirements for all manners of existing
> > protocols.
> >
> > If we are going to define a new protocol type, let's define one that
> > addresses everything we are currently struggling with and has the
> > extensibility to address additional requirements moving forward into
> > the future.
> >
> > Thanks - Fred
> > > > > If the PMTU less than the size of the payload plus the UDP
> > > > > header
> > > > plus
> > > > > unconventional packets, it is reassembled at the transport
> layer.
> > > If
> > > > > > > > I agree that C.M. Heard's ideas should be explored in
> more
> > > > > > > > detail
> > > > > > by
> > > > > > > > the IETF.
> > > > > >
> > > > > > In an offline discussion with Mark Smith and I kicked around
> > > > > > an
> > > > idea
> > > > > > relying instead on the redundancy of the UDP Length field.
> > > > > > The
> > > UDP
> > > > > > discarded and are not delivered to the application; that is
> > > > > > the behavior of the implementations I know of.
> > > > > >
> > > > > >      0                            15 16
> > > > 31
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |                          data octets               ...
> > > > > > segments.  We set the Length and Checksum fields as usual,
> and
> > > then
> > > > > cut
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |                         Identification
> > > > |
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |                          data octets               ...
> > > > > > We put the same UDP header in each segment, so (if we take
> > > > > > some
> > > > care
> > > > > in
> > > > > > how we choose the length of the segments) each one will have
> a
> > > UDP
> > > > > > combined length of any extension headers.  Implementations
> > > > > > that
> > > > > conform
> > > > > > should not mistakenly consider the segmentation fields as
> part
> > of
> > > > > > datagrams, and some existing erroneous implementations may
> > > > > > fail
> > > to
> > > > > > Note that this idea does not work with UDP-lite, which
> > > > > > replaces
> > > the
> > > > > > Length field with a Checksum Coverage field.  That could
> > > > > > easily
> > > be
> > > > > too
> > > > > > -------------------------------------------------------------
> -
> > > > > > -
> > --
> > > --
> > > > -
> > > > > > -------------------------------------------------------------
> -
> > > > > > -
> > --
> > > --
> > > > -
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> -
> > > > > -
> > --
> > > -
> > > > > IETF IPv6 working group mailing list [email-masked]
> > > > > Administrative Requests:
> > > > > ---------------------------------------------------------------
> -
> > > > > -
> > --
> > > -
> > > >
> > >
> >

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Aug 2013 12:31:58 +1000

> [email-masked]

There are several issues with getting fragments through firewalls.
My draft addresses one of them.

Putting all the headers into the initial fragment is another part
of fix / reducing the issue.  If you don't do something like that
firewall will drop initial fragments because that can't be expected
to reassemble unless they are doing DPI.

Making fragment sizes more even is yet another part of the issue.

Allowing tunnel entry points to re-fragment fragments is yet another
part of the solution space.

Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Aug 2013 14:50:55 +0000

Hi Ron,

> Sent: Tuesday, August 06, 2013 6:46 PM
> a) Remove network administrators' motivation for blocking IPv6
> fragments. To this end, we assume that the network administrators'
> primary motivation is the tiny fragment problem. So, we solve the tiny
> fragment problem by changing the way that IPv6 fragmentation works. In
> the new fragmentation scheme, each fragment contains parsable
> information regarding the payload protocol and port.
> 
> b) Make UDP-based applications work in a world where network
> administrators block IPv6 fragments. We do this by either modifying UDP
> so that it supports fragmentation and reassembly of long payloads or
> creating a new UDP-like protocol that supports the fragmentation and
> reassembly of long payloads.
> 
> Draft-andrews-6man-fragopt solves the problem posed in draft-bonica-
> 6man-frag-deprecate by solving problem a). Mike's proposal solves the
> problem posed in draft-bonica-6man-frag-deprecate by solving problem
> a).
> 

SEAL solves the problem too. Transport-mode SEAL took me 15 minutes
to write, and is really just a couple of paragraphs. In addition to
providing a universal sublayer that can handle any transport protocol
'X', SEAL also provides an RFC4821 path MTU probing facility. And, if
ingress filtering is thought to be a problem, it also provides a data
origin authentication facility.

It seems Ron that you are trying to avoid a closer examination of SEAL.

Thanks - Fred
 
> protocol
> > > > b) It reuses UDP transport machinery. (The only exception is the
> in
> > > > LENGTH field)
> > > > c) It reuses IP fragmentation machinery (moving it to the
> transport
> > > > layer)
> > > > > > > The idea was essentially UDP with segmentation fields,
> which
> > > > would
> > > > > > > for an alternate version not requiring a new protocol
> number,
> > > but
> > > > > > > rather relies on the length reported by the IP layer.
> Under
> > > > > current
> > > > > > > standards, the UDP Length field must be at least 8 and
> cannot
> > > > > exceed
> > > > > > > implementations are supposed to drop UDP datagrams that
> fail
> > > this
> > > > > > >     |                          data octets
> > > > > > >     |                          data octets
> > > > > > > Length field that is greater than the IP payload length
> minus
> > > the
> > > > > > > UDP datagrams to safely coexist with conventional
> unsegmented
> > > > one,
> > > > > > without
> > > Administrative

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Aug 2013 14:57:16 +0000

Hi Mark,

> From: Mark Andrews [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2013 7:32 PM
> To: Templin, Fred L
> Cc: Doug Barton; [email-masked]
> In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-
> 504.nw.nos.boeing.com>, "Templin, Fred L" writes:

In these points, you are making a good case for SEAL.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Aug 2013 17:44:34 +0000

Here's another thing to mention on this subject. Defining a new IP
protocol number is great, but might be blocked on paths that only
accept legacy protocols such as UDP and TCP (I believe SCTP and
DCCP suffer from this issue). So, SEAL provides a UDP encapsulation
format and defines a new UDP port number for SEAL. In that case,
the transport mode encapsulation for SEAL looks like this:

  +---------------------+
  |      IP header      |
  |   (Nexthdr = UDP)   |
  +---------------------+
  |   Outer UDP header  |
  |     (port = SEAL)   |
  +---------------------+
  |     SEAL Header     |
  |   (Nexthdr = UDP)   |
  +---------------------+
  |   Inner UDP header  |
  | (port = Application)|
  +---------------------+
  |                     |
  ~   Application Data  ~
  |                     |
  +---------------------+

This may seem unsavory to some who prefer a "clean" encapsulation,
but may be necessary on some paths.

Thanks - Fred

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Aug 2013 07:54:08 +1000

In message <[email-masked]
m>, "Templin, Fred L" writes:
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20

And all those changes are independent of a SEAL header.  They are
changes to the fragmentation algorithm.

SEAL has a big drawback.  SEAL requires then tunnel endpoint /
destination node to understand SEAL.

My draft does not require any other node to understand the option.
You can start sending packets with the option immediately and they
should be passed by nodes that are not aware of what it does.
Destination nodes can process the fragments without knowning the
contents.  This is no more dangerous than processing fragmented
traffic without the option if you are already passing fragments.
 
The key difference is HEADER vs OPTION.

Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Aug 2013 22:17:17 +0000

Hi Mark,

> Sent: Wednesday, August 07, 2013 2:54 PM
> To: Templin, Fred L
> ---
> ---

But, an attacker does not need to implement the changes to the
fragmentation algorithm in order to be compliant with the specs.

> destination node to understand SEAL.

Right that the destination needs to understand SEAL.

> traffic without the option if you are already passing fragments.

But, does it address the tiny fragment attack profile that Ron's
draft is concerned with? And will it be robust as more and more
operators unconditionally drop IP fragments?

> The key difference is HEADER vs OPTION.

That's right, but without a new header there is no means to probe
the path MTU or even to ping the destination to see if it is up
as part of the protocol. Plus, we need a multiple-part solution
that not only addresses transport-mode UDP fragmentation but also
tunnel-mode operation for tunnels that would otherwise be
susceptible to MTU issues.

Thanks - Fred

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Aug 2013 09:55:31 +1000

In message <[email-masked]
m>, "Templin, Fred L" writes:
> > > >=3D20
> > > >=3D20
> > > >=3D20
> > > >=3D20
> > > >=3D20
> > > >=3D20

Fred, you are missing the point.  You don't need a single ominbus
draft.  One can have multiple drafts that address different points.

Your arguement is that it is not a omnibus draft.  It didn't set
out to be a omnibus draft.

Today legitimate IPv6 nodes send fragments no smaller than 1280
unless the first hop is being mapped to IPv4 at the sending node
and the IPv4 mtu is less than 1280.  1280 bytes contains the full
header chain unless someone is launching a attack.

Today firwalls drop fragments that don't have enough information
in them to work out if the non-initial fragment can pass without
passing all fragments.  The initial fragment is dropped because the
firewall operator knows it is pointless to send it despite there
being enough information.

If attackers sends tiny fragments they will continue to be dropped
with or without this option as the firewall doesn't have enough
information to make the decision in the initial fragment.  Legitimate
initial fragment however can now be let through as the firewall
knows that the other fragments will have the necessary information.
Other fragments can be let through with this option as the firewall
will pass the legitimate initial fragment.

Attackers now have to find the slot/pinhole to send attack traffic
through instead of just letting through all fragments.

Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Aug 2013 15:21:38 +0000

Hi Mark,

> Sent: Wednesday, August 07, 2013 4:56 PM
> To: Templin, Fred L
> > > > > > > > If we are going to define a new protocol type, let's
> define
> > > one
> > > > > > > > that addresses everything we are currently struggling
> with
> > > and
> > > > > > > So in other words let's make all the same mistakes we made
> with
> > > the
> > > > > > > design of IPv6?  :)
> > > > > >
> ----
> ----

You know, I was thinking pretty much the same thing on my way
into work today. SEAL didn't set out to address transport mode,
and until the most recent version left it as "out of scope".
I'm willing to believe that an incrementally deployable approach
such as what you are describing could address transport-specific
requirements. 

> out to be a omnibus draft.

OK.

> will pass the legitimate initial fragment.

But, is the firewall going to do any bounds checking on the
fragmentation offset? Asked another way, is there still an
overlapping fragment attack profile to be concerned with?
 
> > as part of the protocol.

This is one part that still concerns me a bit. Sure, the
application can simply fragment everything larger than 1280
but wouldn't it be better to have an assured path MTU so it
knows whether it can suspend the fragmentation process? I'm
thinking of RFC4821 applied to UDP and/or to specific app's.

Thanks - Fred

> > Plus, we need a multiple-part solution

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Aug 2013 09:53:40 +1000

In message <[email-masked]
m>, "Templin, Fred L" writes:
> > > > > > > > > define one
> > > > > > > > > with and
> > > > > > > > > has the extensibility to address additional requirements
> > > > > > > > > moving forward into the future.
> > > > > > > >
> > > > > > > > with the design of IPv6?  :)
> > > > > > >
> > > > > > firewall will drop initial fragments because that can't be
> > > > > > expected to reassemble unless they are doing DPI.
> > > > > >
> > > > > > Allowing tunnel entry points to re-fragment fragments is yet
> > > > > > another part of the solution space.
> > > > >

If you only pass initial fragments which contain a complete header
chain RFC 2460 behaviour in the node should be sufficient.

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

> thinking of RFC4821 applied to UDP and/or to specific app's.

If it is worth it to the application they can still do it.

For things like DNS, PMTUD isn't worth the effort.  Just fragment
/ segment for a 1280 MTU and be done with it.  Named does that today
though it is still a mess to enable because IPV6_USE_MIN_MTU is not
part of POSIX.  Named deals with stupid firewalls by sending different
sized EDNS UDP buffer sizes in the requests.  Named has to deal
with a effective MTU of 512 + headers as some firewalls still think
DNS/UDP requests can only have a 512 octet payload.  Additionally
DNS is sometimes anycasted so PTB's can go to the wrong instance.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 9 Aug 2013 11:32:10 +0000

Fred,

Quite to the contrary, I have spent a good deal of time reviewing the SEAL draft. (Although I am now one version behind. The document is now in version 61.)

SEAL attempts to solve many problems. These include:

- source address authentication
- detection of packet duplication and reordering
- fragmentation at a layer above IP
- MTU discovery

In order to solve all of these problems, SEAL invents good bit of protocol machinery. Much of this machinery a) already exists at another layer and b) is not required to solve the problem at hand. This makes SEAL a much more heavyweight than the simple point solution that we seek.

                                              Ron

> 
> SEAL solves the problem too. Transport-mode SEAL took me 15 minutes to
> write, and is really just a couple of paragraphs. In addition to

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Aug 2013 15:50:54 +0000

Hi Ron,

Glad to hear you have had a look at SEAL, and see below for
a few follow-up comments:

> Sent: Friday, August 09, 2013 4:32 AM
> Quite to the contrary, I have spent a good deal of time reviewing the
> SEAL draft. (Although I am now one version behind. The document is now
> in version 61.)
> 

I suppose it could be considered source address authentication
in transport mode, but in tunnel mode it is about data origin
authentication. When data origin authentication is enabled, the
tunnel egress has a way of knowing when the tunnel ingress is
authorized to tunnel a packet with source address S. But, the
egress has no way of reaching back to the original source to
know if it is authorized to source a packet with source
address S.

> - detection of packet duplication and reordering

Yes, SEAL provides a well-behaved 32-bit packet sequence number
which can be used by the tunnel far end to keep track of any
duplicate or re-ordered packets.

> - fragmentation at a layer above IP

It is fragmentation at a layer above the outer IP protocol and
below the inner IP protocol. However, cases in which both outer
IP fragmentation and SEAL-layer fragmentation will be applied
are exceedingly rare and will be tuned out as soon as they are
detected.

SEAL fragmentation uses the same header footprint as for IPv6
fragmentation, but the idea is that it would be used as a
short-term facility to make sure the IPv6 minMTU is honored
while arrangements are made to begin sending unfragmented packets.
 
> - MTU discovery

More like "MTU assistance". SEAL tries to do as little as possible
to make sure that no path MTU black holes are exposed by virtue of
tunneling while the original hosts still need to do PMTUD and/or
PLPMTUD. SEAL "takes care of the smalls, and lets the bigs take
care of themselves"; the original hosts will take care of those.

> In order to solve all of these problems, SEAL invents good bit of
> protocol machinery. Much of this machinery a) already exists at another
> layer

I'm not sure I get that. SEAL fragmentation would be used instead
of IPv6 fragmentation to make sure that packets no larger than the
minMTU make it through to the tunnel far end. SEAL fragmentation
is in many ways a simplified version of IPv6 fragmentation and
reuses most of the same code while avoiding the tiny fragment,
overlapping fragment, etc. issues.  

> and b) is not required to solve the problem at hand.

Wait, which problem are we talking about - transport mode or
tunnel mode? I am no longer considering the transport mode case
and have returned my focus to tunnel mode. Are you talking about
transport mode or tunnel mode?

> This makes
> SEAL a much more heavyweight than the simple point solution that we
> seek.

It is no different than GRE plus fragmentation used sparingly
and only as necessary.

Thanks - Fred

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 18 Aug 2013 18:14:49 -0700 (PDT)

Greetings,

Chiming in a bit late, I have a few things to add to the thread:

1.) Ron's paraphrase below captures my intent precisely.

2.) As Fred points out (and as I mentioned in my original post), it 
    is possible that some middleboxes will filter UDP datagrams with 
    UDP Length > L4 length from IP.  However, it would not be 
    difficult to code up some test scaffolding to get at least some 
    empirical data on how frequent this might be.  I am thinking now 
    of something along the lines of the data in Section 5.3 of

    http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

    for IP fragment filtering.  Are any operators out there 
    interested in commissioning/supporting such an effort?

3.) If it turns out that such filtering is common, I agree with Ron 
    that using a new protocol number is the right way to go.  In 
    that case I would further modify the proposal to make the 
    transport header format the same in all cases, in order to 
    simplify implementations (and thereby make them more reliable).

4.) Assuming that such filtering is not common, there are some 
    aspects of the proposal sketched below that may be worthy of 
    further discussion and comment:

    a.) Segments with partial overlap should not be allowed, for
        reasons that are well known to readers of this list (and 
        implementors of IPv4 fragmentation).  A complete overlap can 
        happen if the network duplicates a segment and should 
        probably be allowed.

    b.) A datagram that gets segmented in the manner proposed below
        would need to have at least 16 transport data bytes pushed 
        into the second and succeeding segments, in order to ensure 
        that the initial segment has UDP Length > L4 length from IP.

    c.) It would need to be clearly specified whether Segment Offset
        does or does not include headers.  For definiteness I assume 
        henceforth that it refers to transport data bytes only.

    d.) If padding beyond UDP Length is disallowed in segmented
        datagrams, then the More Segments bit (M) is not needed, 
        since in that case the condition

        UDP Length = (Segment Offset)*8 + (L4 length from IP - 8)

        is equivalent to M=0.  In any case this condition must be 
        satisfied when M=0.  Note that padding cannot be allowed in 
        segments with M=1 (as is the case with all TCP segments).

    e.) We may want to re-consider whether to allow padding beyond 
        UDP Length in non-segmented datagrams.  Existing UDP 
        implementations known to me are liberal on this score -- 
        they ignore padding -- but it may be desirable to eliminate 
        the potential covert channel.  Note that specifying this 
        behavior for non-segmented datagrams would be an update to 
        RFC 768 and RFC 1122, which are silent on the matter.

    f.) Having the datagram length in every segment tells the
        receiver how big a reassembly buffer to allocate, even in 
        the presence of segment reordering.  This has the potential 
        to simplify the implementation and could partially mitigate 
        certain classes of reassembly buffer exhaustion attacks.

Mike Heard

On Tue, 6 Aug 2013, Ronald Bonica wrote:
> d) Aside from b) and c), it introduces no new protocol machinery. So, it 
>  can be described in a few short pages. This is in stark contrast to SEAL 
>  (draft-templin-intarea-seal-61) whose protocol machinery requires 41 pages 
>  to describe which required 61 draft versions to get right.
> 
>                                                  Ron
> 
> 
> > > host emits a conventional UDP packet which is characterized as follows:
> > >
> > > - Protocol = 17
> > > > > > by the IETF.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 18 Aug 2013 19:57:37 -0700 (PDT)

> protocol must ensure that tiny fragments cannot ever be created.

That is incorrect, or at least a red herring.

As draft-bonica-6man-frag-deprecate Section 2.3 points out, tiny 
IP-layer fragments are a problem because thsy can be crafted so that 
the L4 header, or a significant part thereof, does not appear in the 
initial IP fragment.

In the proposal I floated (or variants thereof, like a UDP 
replacement with a new protocol number) where L4 segments are used 
_instead_ of IP fragments that cannot happen, because the L4 header 
appears in front of _each_ segment -- just as with TCP.  Tiny 
transport layer _segments_ have not been identified as a problem.

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 26 Aug 2013 21:37:49 -0700 (PDT)

Greetings,

Upon reflection, I have come to the conclusion that the proposal in 
draft-andrews-6man-fragopt (or a variant thereof) is a much better 
solution to the problems with IPv6 fragmentation than the UDP 
segmentation scheme I proposed.

The huge advantage of putting a skippable IPv6 option with 
higher-layer header information into IPv6 fragments is that it is 
much easier to deploy incrementally than the UDP segmentation 
scheme.  New end systems could begin inserting the option as soon 
the format is standardized, and they would still be able to 
communicate with older end systems that comply with existing IPv6 
specifictions, at least on paths where fragments are not discarded 
by firewalls.  That's not true of the UDP segmentation scheme (or of 
more complex alternatives such as SEAL).

A second advantage of the proposal in draft-andrews-6man-fragopt, 
or more specifically of a variant that I proposed in
http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html, 
is that it can be made to work with any upper-layer protocol, 
present or future.  The UDP segmentation scheme works for one 
protocol only.  (SEAL would work with any upper-layer protocol, but 
since it hides the upper-layer headers, it could well be blocked by 
firewalls for that reason.)

It is true that firewalls will need to be updated to make the option 
scheme achieve its objective of getting fragments through.  It 
seems, however, that the same is true of the UDP segmentation scheme 
that I proposed; Google for "UDP packet length and the size on the 
wire do not match" for some examples.  (SEAL, being a new 
upper-layer protocol, would also require firewall updates).

The main lesson I draw from draft-taylor-v6ops-fragdrop is that IPv6 
fragmentation, as currently specified, does not meet the 
requirements of certain operators because upper-layer header 
information is absent from non-initial fragments.  The option scheme 
directly addresses that problem.  Given that the 6man WG is not 
ready to deprecate IPv6 fragmentation, it seems to me that it should 
be rehabilitated to the extent possible, and I think the option 
scheme would do that.

Thanks and regards,

Mike Heard

On Wed, 7 Aug 2013, Ronald Bonica wrote:
> primary motivation is the tiny fragment problem. So, we solve the 
> tiny fragment problem by changing the way that IPv6 fragmentation 
> works. In the new fragmentation scheme, each fragment contains 
> parsable information regarding the payload protocol and port.
> 
> administrators block IPv6 fragments. We do this by either 
> modifying UDP so that it supports fragmentation and reassembly of 
> long payloads or creating a new UDP-like protocol that supports 
> the fragmentation and reassembly of long payloads.
> 
> Draft-andrews-6man-fragopt solves the problem posed in 
> draft-bonica-6man-frag-deprecate by solving problem a). Mike's 
> proposal solves the problem posed in 
> draft-bonica-6man-frag-deprecate by solving problem [b)].
> 
> > > > > > > > I agree that C.M. Heard's ideas should be explored in more detail by
> > > > > > > > the IETF.
> > > > > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Aug 2013 15:15:03 +0000

Hi Mike,

I said a while back that Mark's proposal is fine for transport mode applications,
but for tunnels we still need something like SEAL. I will replay my message from
an off-list discussion below:

Fred

"Hi, I am not exactly sure where tunnels fit with this discussion but here is my
thinking on tunnels:

1) Tunnels absolutely require some form of fragmentation/reassembly of the
encapsulated packet, as established in 'draft-generic-6man-tunfrag'. This applies
to all tunnels over both IPv4 and IPv6.

2) Since in-the-network fragmentation/reassembly is painful, the tunnel ingress
needs some way of knowing when it is OK to turn it off. For that purpose, we
need RFC4821 for tunnels.

3) RFC4821 probing needs to occur in-band within the ordinay tunneling protocol
messages; otherwise, the probes might take a different path than the ordinary
messages. (The same is true of RFC4821 applied to TCP.)

4) In order to probe the path in-band, the tunneling protocol encapsulation needs
(at a minimum) a "probe" bit and a probe acknowledgement message. That means
that the tunneling protocol needs either a new encapsulation format or a new
version number.

5) Since the same probing process applies to all forms of tunnels (IP/IP, GRE,
IPsec, etc) it would be best to have a generic encapsulation format that applies
equally to all.

6) This new encapsulation format can reuse the bulk of the IPv6 fragment header
format as well as the vast majority of the IPv6 fragmentation and reassembly code.

7) While defining a new fragmentation header format for tunnels, change the
fragment offset field to 8 bits (down from 13) which encodes an integer multiple
of 256 byte segments, i.e., the minimum fragment size is 256 bytes.

We were discussing tunnels several weeks ago before the discussion vectored
off into transport mode considerations. Do we want to start discussing tunnels
again under this thread, or should it be a separate thread?"

> Sent: Monday, August 26, 2013 9:38 PM
> To: IPv6
> address
> > > > > b) It reuses UDP transport machinery. (The only exception is
> the in
> > > > > LENGTH field)
> > > > > > > The proposal sounds elegant. I will try to paraphrase it to
> make sure
> > > > > > > that I understand.
> > > > > > >
> header plus
> > > > > > > - Segment Offset, M-bit and Identification fields added to
> UDP header
> > > > > > > before the payload
> > > > > > >
> layer. If
> more detail by
> which would
> number, but
> The UDP
> cannot exceed
> fail this
> possible to re-
> segmented UDP
> intepreted
> indicated
> and then cut
> some care in
> minus the
> that conform
> part of the
> fail to do
> replaces the
> easily be too

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Aug 2013 17:18:51 -0400

> be rehabilitated to the extent possible, and I think the option 

Apologies if I missed it and this was already discussed -- for some reason my MUA is refusing to thread this conversation correctly and so I'm reading thing all out of order…

I have some issue / concerns with draft-andrews-6man-fragopt 
The whole problem is that I cannot look at the fragment and know what protocol and port it is actually destined to (I also have concerns about past issues with reassembly / overlapping frags, but we'll skip those for now).
I am unclear how I am supposed to be able to trust the port information in the new header?

Lets say that I only allow traffic to 192.0.2.1 port 80.
What is to stop a malicious party from:
1: Generating a packet to 192.0.2.1 port 22.
2: Fragmenting it into two parts.
3: Adding a few junk headers for padding (I think that this is optional)
4: Putting in this new header and listing the destination port as 80?

I *guess* if *all* of the devices on the inside of my network know to check that the new header attributes match the reassembled pack then I have *some* protection, but this isn't (that I could see) specified in the draft. 
There are some comments about NATs changing things "both the source and destination ports may have been changed so the ports may appear to be completely unrelated. The
   source port is changed by a client NAT and the destination port is
   changed by a NAT acting a load balancer."

It is conceivable that all of the devices behind a load balancer could be configured to ignore this check, but that removes basically all of the protection (same thing if the LB simply strips this option).

W

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 07:46:24 +1000

Warren can you please fix your MUA to generate legal To: lines.
"To: C. M. Heard <[email-masked]>" is not legal a legal To: line.

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

In message <[email-masked]>, Warren Kumari wri
tes:
> Apologies if I missed it and this was already discussed -- for some
> reason my MUA is refusing to thread this conversation correctly and so
> I'm reading thing all out of order.
>
> The whole problem is that I cannot look at the fragment and know what
> protocol and port it is actually destined to (I also have concerns about
> past issues with reassembly / overlapping frags, but we'll skip those for
> now).
> I *guess* if *all* of the devices on the inside of my network know to
> check that the new header attributes match the reassembled pack then I
> have *some* protection, but this isn't (that I could see) specified in
> the draft.
> There are some comments about NATs changing things "both the source and
> destination ports may have been changed so the ports may appear to be
> completely unrelated. The
> It is conceivable that all of the devices behind a load balancer could be
> configured to ignore this check, but that removes basically all of the
> protection (same thing if the LB simply strips this option).
>
> W

Assuming you don't have a load balancer that is changing the destination
port the destination port will still be port 80 on all fragments in both
the hop-by-hop option and the original TCP header.

You still need to drop initial fragments where you can't see the entire
header chain.

Passing a fragment is no worse than passing a out of order segment.

Reply traffic will still be from port 80 but after it has passed
through a NAT the destination port in the option will not match the
original source port. 

Again you still need to drop initial fragments where you can't see
the entire header chain.

You have looser rules on the non-initial fragments than for the
initial fragments.  But it is not wide open like it currently has
to be.

Mark

> So,
> Behalf Of
> rather

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 27 Aug 2013 19:08:09 -0700 (PDT)

On Tue, 27 Aug 2013, Warren Kumari wrote:
> Apologies if I missed it and this was already discussed -- for 
> some reason my MUA is refusing to thread this conversation 
> correctly and so I'm reading thing all out of order?

Ah, an operations person joining the discussion!  Thank you!

> The whole problem is that I cannot look at the fragment and know 
> what protocol and port it is actually destined to (I also have 
> concerns about past issues with reassembly / overlapping frags, 
> but we'll skip those for now).
> 

It is indeed possible to forge the option with upper-layer header 
information that is proposed to be passed in the option.

> 4: Putting in this new header and listing the destination port as 80?

In http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html 
(which you may not have seen yet) I suggested that the upper-layer 
header option should not be allowed in the initial fragment, which 
contains the real upper-layer header.  If it's there, your firewall 
(if it's been updated as proposed) should drop the datagram.  If 
it's not, the datagram should be dropped because it has port 22 in 
the upper-layer header, in violation of the configured policy.

Mark Andrews emphatically disagreed with my suggestion; but in that 
case, the initial fragment would have both the option and the 
upper-layer header, and they would not match (the option has port 80 
and actual upper-layer header has port 22).  That should make your 
firewall recognize that the initial fragment is bogus and drop it.

In any case, the initial fragment should get dropped.

Now, your firewall (if it's updated per either variation of the 
proposal) would allow the non-initial fragments to pass on (since 
the option says they are destined to port 80).  But those won't 
reassemble to a complete datagram on the destination host.

I imagine that your next question (and one that I _should_ have 
asked myself) is: how is this different from what we get from the 
combination of draft-ietf-6man-oversized-header-chain and 
draft-ietf-6man-ext-transmit, _without_ the upper-layer header 
option?  The answer is that it's not different, at least not in a 
significant way.  This is what would happen today if one applied 
stateless ACLs at layer 4 to initial fragments that contain a 
complete header chain but allowed non-initial fragments to go 
through unimpeded.

Your firewall could do some checks like looking at the length of the 
upper-layer PDU claimed in the copy of the upper-layer header in the 
option (for protocols like UDP that have a length field, and if the 
option is formatted as I proposed) and then discard any non-initial 
fragments that have offsets past the end of the upper-layer data.  
However, it would still be possible for someone to send a bunch of 
non-initial fragments whose reassembly would never complete on the 
destination end host.

> I *guess* if *all* of the devices on the inside of my network know 
> to check that the new header attributes match the reassembled pack 
> then I have *some* protection, but this isn't (that I could see) 
> specified in the draft.

Actually, no.  I suggested that end systems (where reassembly is 
done) should do this check if they can process the upper-layer 
header option.  But that would not prevent them from getting a 
series fragments whose reassembly would never complete: all that an 
attacker needs to do is send an incomplete series of fragments.  
The gap can occur anywhere, and the upper-layer header option need 
not be forged (i.e., it could match the contents of the header in 
the initial fragment and pass all ACL checks).

FWIW, the UDP segmentation proposal that I floated earlier in this 
thread suffers from the exact same problem.

One of the other the issues mentioned in draft-taylor-v6ops-fragdrop 
is the problem of stateless load balancers that use the 5-tuple in 
initial fragments and (say) the 2-tuple in non-initial fragments.  
To the extent that it is considered trustworthy, the proposed 
upper-layer header option (with appropriate middlebox modifications) 
would fix this problem (as would the UDP segmentation proposal, at 
least for UDP), but then again, so would the use of the flow label 
as described in RFC 6437.

OK, it seems that the ideas floated in this thread don't go really 
beyond what's already been standardized or (apparently) agreed upon 
here in 6man, and as far as I can see, the problem of an attacker 
being able to send a series of fragments whose reassembly will never 
complete is basically unsolvable.  So let me ask a question: is this 
a sufficiently serious problem to be worth breaking fundamental 
connectivity for those protocols that don't have a good alternative 
to fragmentation?

> There are some comments about NATs changing things "both the 
> source and destination ports may have been changed so the ports 
> may appear to be completely unrelated. The source port is changed 
> by a client NAT and the destination port is changed by a NAT 
> acting a load balancer."

Just out of curiousity -- is this actually an issue in operational 
IPv6 networks?

Thanks,

Mike Heard

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Aug 2013 17:11:10 +0000

Hi Mike,

> Sent: Tuesday, August 27, 2013 7:08 PM
> To: IPv6
> Subject: Re: [6MAN] UDP+Fragmentation (was: "Deprecate")
> 
> complete is basically unsolvable.

If each fragment contains a Message Authentication Code (MAC), the
destination can discard fragments that are either missing or contain
an incorrect MAC value. (Yes, this opens up other issues such as
attacks on performance for running the MAC algorithm.) 

> So let me ask a question: is this

Tunnels need fragmentation to meet the 1280 IPv6 minimum MTU, and
preferably also to meet the 1500 legacy Internet cell size.

Thanks - Fred