Subject: Re: Moving forward draft-ietf-6man-oversized-header chain?

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Feb 2013 08:38:01 -0500

On Friday 8th Feb 2013, Karl Auer wrote, in part:
> Do you mean that the ESP header must be the first item in the
> fragmentable part of the first fragment? Or that the ESP header
> must be (at least partly) in the non-fragmentable part of the
> first fragment?

I can't lex your question, so please forgive me for 
starting from first principles.  :-)

As the name Encapsulating Security Payload (ESP) implies, 
ESP *encapsulates* other information, (seeks to) protect 
the encapsulated information, and ESP is always a 
terminating payload.  

Put another way, while ESP might contain something else
(e.g. an encrypted blob that if successfully decrypted
becomes a TCP header and TCP data segment), ESP is itself
always the last payload in the original on-the-wire packet.

In the general case, the ESP is encrypted, so the only 
parseable object is the SPI, which consists of the first 
few bytes of the ESP.  The SPI is used to demux different
ESP-protected sessions so that a legitimate recipient
can learn which cryptographic keys/algorithms/modes 
to apply to the ESP in order to retrieve the protected
information.

While various techniques for parsing an ESP that might not 
be encrypted have been proposed, none seems completely 
(i.e. 100.00%) reliable.  Separately, the proposed WESP 
extension appears to have zero implementations, and no
support in any router/middlebox/firewall/NAT device.
So WESP turns out to be irrelevant for this discussion.

> If the latter, that's a new kind of animal.

Not at all.  ESP isn't an optional intermediate header.
ESP always is an optional terminating payload, optional
in the sense that a packet could contain other terminating
payloads (e.g. UDP, TCP, SCTP, ICMP).

> At present, a header is either completely in the
> non-fragmentable part or completely in the fragment able
> part.  Permitting a header to straddle the fragment header
> seems odd,

It is already the normal case for ESP.  At present,
ESP might be partly in a first fragment, split between
two fragments, or entirely in a non-first fragment.

> and I can't immediately see how you could do it without
> changing the fragment header definition, either.

In turn, your confusion puzzles me.
Does the above explanation help at all ?  

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Feb 2013 14:36:11 +0000

> On Friday 8th Feb 2013, Karl Auer wrote, in part:

...
> In turn, your confusion puzzles me.

Me too. TCP is also an encapsulating header; its contents just don't happen
to be encrypted. The draft's definition of "Entire IPv6 header chain" uses
TCP as an example:

         Note: If there is an upper layer header, only the header (and
         not its payload) are considered part of the "entire IPv6 header
         chain".  For example, if the upper layer protocol is TCP, only
         the TCP header (and not its possible data bytes) should be
         considered part of the "entire IPv6 header chain".

but I don't think it would be any different for ESP.

However, I do see one point that is under-defined right now:

**How many bytes of the transport header+payload are included in this definition?**

For ESP, is it 8 bytes (SPI + Sequence Number)?

For TCP, is it 8 bytes (ports + Sequence Number)?

etc.

The draft also defines "Extension Headers":
      Any Extension Headers as described in Section 4 of [RFC2460], and
      specified in [RFC2460] or any subsequent documents.

FYI, we have included a complete list of extension headers in
draft-carpenter-6man-ext-transmit, and a related IANA proposal.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Feb 2013 10:17:17 -0500

On 08  Feb 2013, at 09:36 , Brian E Carpenter wrote:
> Me too. TCP is also an encapsulating header; its contents
> just don't happen to be encrypted. The draft's definition
> of "Entire IPv6 header chain" uses TCP as an example:
> 

I think that would be OK.  Certainly it MUST NOT be
more than those 8 bytes, because beyond there lies
encrypted bits (in the general case).  

I actually believe that the SPI alone would suffice
for ESP.

> For TCP, is it 8 bytes (ports + Sequence Number)?

My own sense is that Source Port and Destination Port,
so 32 bits, actually would suffice, but I'll at least 
note one possible counter-argument:
	A firewall implementation might want to look 
	at the TCP flags to check for invalid flag 
	combinations.

For UDP, my own sense is that the first 32 bits
would suffice, although I don't see any harm in
including the first 64 bits.

I would have no objection to Fernando adding more
detail for the obvious terminating payloads
(e.g. UDP, TCP, SCTP, ICMP, ESP) to the draft.

Adding more clarity about this to the I-D could not hurt, 
and might help some implementers.

Yours,

Ran

---

From: Karl Auer <[email-masked]>
Date: Sat, 09 Feb 2013 05:26:56 +1100

> > must be (at least partly) in the non-fragmentable part of the

I had completely misunderstood what the person I was replying to meant.
There was a third option which Fernando put admirably clearly later,
i.e., simply that the beginning of the ESP header had to be in the first
fragment. How much of the beginning of te ESP header needs to be present
in the first fragment is, as you pointed out, a good question.

The following explanation is thus pretty pointless, but just for laughs:

> Not at all.

I was (erroneously) imagining that someone was suggesting that some part
of the ESP header should precede the fragment header in the first
fragment (i.e., in the non-fragmentable part), with some part of the
rest of the ESP header following in the fragmentable part. That would
definitely be a new animal :-)

> two fragments, or entirely in a non-first fragment.

Sure - but the ESP header never straddles a fragment header. The
fragment header, if present, is always the last thing in the
non-fragmentable part. I was imagining a scenario where this was no
longer the case.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Feb 2013 18:42:01 -0300

> encrypted bits (in the general case). 

Quickly skimming through RFC4303, it looks like the first 8 bytes of the
ESP header are referred to as "header" (with the other being referred to
as "payload" and "trailer").. so it looks like ESP wouldn't really be a
"special case".

Should we clarify "how many bytes are included" for ESP, nevertheless?

> I actually believe that the SPI alone would suffice

It probably would, but.. since the Seq # is part of the header, and it
is also transmitted in plain text, I'd personally deal with ESP as with
the general case "the entire ESP header" (IMO, the fewer the "special
cases", the better).

> 	at the TCP flags to check for invalid flag 

In general, firewalls tend to look at many fields in the upper-layer
header -- so it's useful to have it all.

> and might help some implementers.

Something that might make sense is to specify something along the lines
of "if the size of the upper layer header is unknown (say, the upper
layer protocol is implemented as a loadable module, in userland, or the
like).

Thoughts?

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Feb 2013 07:57:37 +0000

> layer protocol is implemented as a loadable module, in userland, or the

If you specify a minimum of 8 bytes that would cover most cases, wouldn't it?

I don't think you will find much enthusiasm among coders for a case statement
that adjusts the number of bytes according to the layer 4 protocol.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 09 Feb 2013 06:11:53 -0300

> If you specify a minimum of 8 bytes that would cover most cases, wouldn't it?

Not really. Firewalls look at many fields in the layer-4 headers -- and
such stuff can be past the first 8 bytes. e.g. OpenBSD PF looks at stuff
such as the initial TCP window for passive OS fingerprinting, such that
you can filter based on the OS type. For instance, the ability to look
at the TCP flags is mandatory for most firewalls.

> that adjusts the number of bytes according to the layer 4 protocol.

There are a number of places where this could be taken care of:

* The IPv6 layer, with a case statement (as you describe) -- there are
not that many upper-layer protocols, anyway.
* The transport layer (where you know the MTU, and you know how many
bytes you're sending down the stack
* The user application (If you're going to insert extension headers, do
the math and make sure all the headers make it into the first fragment)

If we fail to include critical information in the first fragment, such
traffic will be dropped even more than it currently is.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Feb 2013 11:11:50 +0000

> at the TCP flags is mandatory for most firewalls.

But the job of this draft is to specify the "on the wire" behaviour of a
sending host. To do that, as far as I can see, you have specify how many
bytes of the transport header MUST be in the first fragment. Does it include
TCP options, for example? At the moment, the draft doesn't tell me what
to put in the code (regardless of where in the host stack this is coded).

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 09 Feb 2013 16:39:34 -0300

On 02/09/2013 08:11 AM, Brian E Carpenter wrote:
> sending host. 

Exactly: And it requires to include all header up to the entire layer-4
header.

> To do that, as far as I can see, you have specify how many
> TCP options, for example?

Yes. TCP options are part of the TCP header... so they should be there.

The short story is: all sort of devices are used to look at the layer-4
header. Legitimate traffic won't have the ipv6 header chain spanning
multiple fragments. So such packets will be dropped. We need to flag
them as appropriate, such that folks that might possibly send those
packets are aware that those packets won't probably survive in the network.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Mon, 11 Feb 2013 22:42:22 +0100

Fernando,

> Should we clarify "how many bytes are included" for ESP, nevertheless?

anything that has a next header field is not the upper layer header.
the middlebox doesn't have access to anything following the ESP header.

> the general case "the entire ESP header" (IMO, the fewer the "special

what about ESP with NULL encryption?

what you are trying to archive is "the first fragment should include as much of the header chain as would be available if the packet
was reassembled", right? perhaps phrase it along those lines.

cheers,
Ole

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 11 Feb 2013 16:51:53 -0500

> what about ESP with NULL encryption?

In the general case, there is no way to reliably (i.e. 100.00%)
know whether a transit ESP packet is using encryption or not.

There are published heuristics that seek to identify ESP
packets that might not be encrypted, but I don't know of
any fully reliable heuristics one might use (see above
for my definition of reliable).

Also, the IETF standardised WESP, but after asking around
and looking, I can't find even one implementation of WESP.  
So WESP appears to have either zero deployment or ignorably
low deployment.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Feb 2013 20:20:13 -0300

Hi, Ole,

On 02/11/2013 06:42 PM, Ole Troan wrote:
>>> I think that would be OK.  Certainly it MUST NOT be more than
>>> those 8 bytes, because beyond there lies encrypted bits (in the
>>> general case).
>> 
>> Quickly skimming through RFC4303, it looks like the first 8 bytes
>> of the ESP header are referred to as "header" (with the other being
>> referred to as "payload" and "trailer").. so it looks like ESP
>> wouldn't really be a "special case".
>> 

Not sure what you mean. You mean that we shouldn't refer to ESP as an
"upper-layer header"? Or something else?

>>> I actually believe that the SPI alone would suffice for ESP.
>> 
>> It probably would, but.. since the Seq # is part of the header, and
>> it is also transmitted in plain text, I'd personally deal with ESP
>> as with the general case "the entire ESP header" (IMO, the fewer
>> the "special cases", the better).
> 

Please see Ran's response.

> what you are trying to archive is "the first fragment should include
> as much of the header chain as would be available if the packet was
> reassembled", right? perhaps phrase it along those lines.

I would specify everything "from the sender side", since that where the
decision is to be made (e.g., "must include the entire IPv6 header chain
available prior to any possible fragmentation").

FWIW, if ESP is used, the encrypted bytes are the payload (not the
header), and hence we're fine. If tunneling is being employed (whether
with IPsec or with something else), anything inside the tunnel is,
strictly speaking, a different layer -- so including everything up till
the ESP header would be okay.

Thougths?

Thanks!

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Feb 2013 09:14:29 +0100

> the ESP header would be okay.

from the sender's perspective the ESP header is an intermediate header.
you need to make it clearer in the draft what you expect to see on the wire and how the host is supposed to behave.

cheers,
Ole