Subject: (IPng 7484) Re: Last Call: IPv6 Jumbograms to Proposed Stand ard

From: Richard Draves <[email-masked]>
Date: Sun, 9 May 1999 23:36:15 -0700

> 	I found that it is very hard to use jumbo payload 
> option with IPsec
> 	AH.  It may be good to add a notice somewhere.  (but this is
> 	NOT a big deal, just add one line and it should be fine 
> - it should
> 	not affect the standard process, at all)
> 
> 
> 	Suppose that the policy asks for two AH, and the packet 
> is nearly
> 	64K of size.
> 
> 	When attaching first AH, the payload length fits in 64K.
> 	AH crypto checksum will be performed for the underlined part.
> 		IPv6 AH1 payload
> 		================ AH1
> 	Then, by adding second AH, the payload size exceeded 64K.
> 	We'll need to add jumbo payload option.
> 		IPv6 HBH(jumbo) AH2 AH1 payload
> 		=============================== AH2
> 
> 	When the receiving node sees the packet, it will verify 
> AH2, then
> 	remove AH2, modify the packet size field in jumbo 
> payload option.
> 		IPv6 HBH(jumbo) AH2 AH1 payload
> 		=============================== AH2
> 			v
> 		IPv6 HBH(jumbo) AH1 payload
> 	Here, the size field in jumbo payload option will be 
> come less than
> 	64K.  The packet is not trivial for receiving node to 
> process, because:
> 	- it can be wrongly formatted packet by the source (a 
> packet with
> 	  illegal jumbo option), so receiving node cannot 
> simply strip off HBH
> 	- how to strip off HBH anyway?  what if you have other 
> HBH options
> 	  on the HBH part?  padding?
> 
> 	In my implementation I disallowed AH on jumbograms - it is the
> 	easiest solution :-P

I don't think this is an inherent problem with jumbograms. In MSR IPv6, we
only have receive-side support for them but we do have support for multiple
AH headers. I believe we would have no problems combining jumbograms with
AH. Our receive-side processing (both for jumbo & AH) does not modify the
received packet, it tracks things like packet size & security associations
separately. Our send-side processing does not create the headers
incrementally, so both AH headers would know about the packet's final header
layout & size.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Aaron Griggs" <[email-masked]>
Date: Mon, 10 May 1999 09:21:58 -0400

So the KAME stack, does IPSec headers incrementally both on the send and
receive side?  Meaning for:
    IP_AH2_AH1_DATA

The IP payload length is different for the authentication done for AH1
opposed to AH2.  As Rich mentioned, the MSR IPv6 stack on the send side
inserts all the IPSec headers for a specific IP area (IP_<IP area>_DATA).
This gets the IP payload to the final size.  Then, we authenticate the IP
packet skipping any nested IPSec headers that come before the AH header
being processed.  For the example above on the send side, AH2 is not
included when AH1 is authenticated but the IP payload length accounts for
AH2.  On the receive side, AH2 is discarded after it is processed (why we
have to skip AH2 on the send side) and we don't adjust the IP payload
length.

So your stack adjust the payload length after AH2 is processed on the
receive side?  I guess if you have an association with a "bump-in-the-stack"
and "bump-in-the-wire" like so:

H----------BW---------BS

BS->H (IP_AH(BW)_AH(BS)_DATA)

Host (H) has an AH association with BW (bump-in-the-wire) and another AH
association with BS (bump-in-the-stack).  BS doesn't know about BW when it
does IPSec.  So if BW does transport mode AH, H would have to change the IP
payload length of the received packet after processing the AH(BW) header.
Of course, I'd say BW can only do tunnel mode unless there was no IPSec done
by BS.

The skipping of nested IPSec headers is what I was interested in finding out
a few weeks back.  It seems some IPSec implementations only handle the
require IPSec header combinations.  Meaning, the problem of IP_AH_AH_DATA
doesn't occur.  If you do handle arbitrary nesting of IPSec headers and you
don't include the affects of a nested IPSec header as in the example (change
in the IP payload length), you get problems like the jumbogram issue.

So the easiest solution would be to only handle the required IPSec header
combinations.  Thus, eliminating the IP header adjustments brought about by
AH_AH.

Aaron

---

From: [email-masked]
Date: Mon, 10 May 1999 22:31:47 +0900

>receive side?  Meaning for:
(snip)
>BS->H (IP_AH(BW)_AH(BS)_DATA)

	Yes for both sentence, that is what I implemented.  I figured this
	out from the processing rules in tunnel-mode, but I may be wrong....
	If there's any mention in the IPsec spec please let me know.  I may be
	missed some descriptions in the spec.

	I'll try testing multiple AHes with other IPsec implementations.
	KAME and MSR IPv6 will not interoperate, apparently...

>combinations.  Thus, eliminating the IP header adjustments brought about by

	Yes, I agree.  Our policy engine was generic enough to support multiple
	AH so I just would like to respect the policy engine :-)

itojun

---

From: "Aaron Griggs" <[email-masked]>
Date: Mon, 10 May 1999 10:32:11 -0400

Hi Itojun,

> missed some descriptions in the spec.
I don't remember anywhere in the IPSec spec (rfc 2401) describing what to do
for this case.  The AH Spec (rfc 2402) states:

< start excerpt rfc 2402>
3.3  Outbound Packet Processing
    ...
   If there is more than one IPsec header/extension required, the order
   of the application of the security headers MUST be defined by
   security policy.  For simplicity of processing, each IPsec header
   SHOULD ignore the existence (i.e., not zero the contents or try to
   predict the contents) of IPsec headers to be applied later.  (While a
   native IP or bump-in-the-stack implementation could predict the
   contents of later IPsec headers that it applies itself, it won't be
   possible for it to predict any IPsec headers added by a bump-in-the-
   wire implementation between the host and the network.)
< end excerpt rfc 2402>

To me, the spec should state for "interoperability" and not "simplicity" the
other IPSec headers MUST be ignored.  However, does ignore mean to remove
there affect on the IP payload.  The MSR IPv6 stack thinks not.  I think
getting a concensus on what other IPSec stacks do is in order.  We know two
now.

You pointed out a problem in the way you do it with regards to jumbograms
which we don't seem to encounter.  There may be some problems with how we do
it for other things.

Thanks,

Aaron

---

From: Craig Metz <[email-masked]>
Date: Mon, 10 May 1999 13:55:41 -0400

>combinations.  Thus, eliminating the IP header adjustments brought about by

  Last time I checked, the specs were worded to not allow arbitrary
combinations of {ESP,AH} (such as the AH AH case you describe). In the IPv6
case, I believe that you can find the allowed combinations described in the
IPv6 proper spec's description of chained header ordering. There's no
technical reason why you can't make arbitrary combinations work; I have code
that should do it just fine. The main problem has actually been that most
systems' internals don't have a framework for building arbitrary headers in
arbitrary orders, so fixing the order simplifies implementing IPv6/IPsec in a
stack.

									-Craig

---

From: Craig Metz <[email-masked]>
Date: Mon, 10 May 1999 14:05:11 -0400

>getting a concensus on what other IPSec stacks do is in order.  We know two

  Ignoring extra IPsec headers should be a local policy decision. You are
welcome to implement your stack to ignore them, but please do not force this
restriction upon others.

  The issue of how the specs model the building/removal of chained headers was
discussed in detail and settled something like three or four years ago,
probably on this list (if not, then the IPsec list).

	 								-Craig

---

From: "Aaron Griggs" <[email-masked]>
Date: Mon, 10 May 1999 14:18:58 -0400

Hi Craig,

> combinations of {ESP,AH} (such as the AH AH case you describe).

Which specs are you referring.  None of the IPSec specs, rule out arbitary
combos of IPSec headers.

>In the IPv6

Are you talking about arbitary extension headers including IPSec?  We handle
that fine although we don't implement them all yet.

I basically want to find out what other implementations do with regards to
nested IPSec headers.  As Itojun pointed out, his stack has problems with
nested AH_AH and jumbograms.  And his stack will not interoperate with ours
if AH_AH is done since he does the IPSec incrementally.

Aaron

---

From: Craig Metz <[email-masked]>
Date: Mon, 10 May 1999 14:23:48 -0400

>Which specs are you referring.  None of the IPSec specs, rule out arbitary

  RFC 1826 did, though subtly (see section three). RFC 2402's rewording makes
it much more fuzzy; its wording can be interpeted either way.

>if AH_AH is done since he does the IPSec incrementally.

  We (NRL) always do them incrementally.

									-Craig

---

From: "Aaron Griggs" <[email-masked]>
Date: Mon, 10 May 1999 15:30:23 -0400

By "ignore," I mean for the ICV calculation only.

If you are doing IPSec incrementally, you don't have to worry about ignoring
because there is nothing to ignore.  You don't know about any subsequent
IPSec headers that may be added later.  In this example:
    IP_AH2_AH1_DATA

On the send side I ignore the AH2 header when doing AH1 authentication.
However, AH2 was factored in to the IP->Length size.  On the receive side
after AH2 is processed, I don't reduce the IP->Length size.  This means if
NRL and MSRIPv6 did AH_AH, we would authenticate AH2 fine but fail on AH1
since the IP->Length field was different when authenticated.

So does ignore mean only ignore the header or its affect on other fields
(IP->Length).  If you do not factor in the final size, the jumbogram issue
can occur.  To be honest, I didn't think about the jumbogram problem when I
did the design.  Also, the jumbogram problem occurs for AH_ESP as well as
AH_AH.

Aaron

---

From: "Aaron Griggs" <[email-masked]>
Date: Mon, 10 May 1999 16:01:03 -0400

>   In my mind, however, there is now a new and more convincing argument for
> doing this incrementally. The "new" IPsec specs describe a
bump-in-the-wire
> IPsec mode (which was also subtly prevented in the "old" IPsec specs,
because
> it also leads to bad design problems). Suppose that my end host sends out:
>
>   IP_len=X AH[len=X] payload
>
>   And my bump-in-the-wire box wants to insert an AH. If we do things
> incrementally, this is easy:
>
>   IP_len=X+Y AH[len=X+Y] AH[len=X] payload
>
>   If we don't things incrementally, this is hard -- cryptographically
> impossible if the bump-in-the-wire doesn't share the secret key with the
end
> host, actually.
>
>   On the surface, an alternate solution is to remove the length field.
However,
> I believe that you'll find that the base header's next header type field
has
> the same problem if you have a bump-in-the-stack capable of inserting, for
> example, ESP before AH (which used to be outlawed, and I think still is in
the
> IPv6 base spec). There might be other fields that become mutable if you
take
> this approach. Personally, I want as much of my packet protected as
possible,
> so I strongly admonish you to choose solutions that allow protection over
> solutions that preclude it.

Yeah, I sent that example to Itojun in my first email.  My solution was to
not allow the "bump-in-the-wire" to do Transport mode IPSec if IPSec was
already performed, which may not work.  Most of the time a
"bump-in-the-wire" will do ESP (encryption) and probably in Tunnel mode,
right?  Anyway, this is for the arbitrary cases that are not required for
IPSec conformance; but, do make "interesting" converstations.

Thanks,

Aaron

---

From: Craig Metz <[email-masked]>
Date: Mon, 10 May 1999 15:57:33 -0400

>IPSec conformance; but, do make "interesting" converstations.

  The solution that used to be the case was not to allow bump in the wire. If
you need an intermediate box to do IPsec, make it encapsulate. Then there are
no problems.

  Apparently, the people responsible for the new IPsec specs decided to change
that. As a result, you are now required to have a stack that can receive
packets from such a box. I don't believe this is an arbitrary conformance
requirement, I think this is a must.

									-Craig

---

From: Craig Metz <[email-masked]>
Date: Mon, 10 May 1999 15:43:22 -0400

>By "ignore," I mean for the ICV calculation only.

  Ah, ok. This was not clear.

>did the design.  Also, the jumbogram problem occurs for AH_ESP as well as

  Like I said, the more general problem of how to assemble and parse chained
headers was discussed years ago. The consensus was that there are reasonable
arguments for doing them incrementally (that is, constructing a fully formed
IP packet at each step, in which case the length field in the IP header for
the two AH computations would be different) and for doing them all at once or
in a two-pass fashion (that is, figuring out the correct values for things and
filling them in as you go, in which case the length field for the IP header
for the two AH computations would be the same -- the bigger length). The
solution I remember was that we really didn't want to choose either way and
preclude an implementation decision, so the specs were written in such a way
that the problem was avoided (which is another reason why you could only have
one AH) and therefore either implementation method would give correct results.

  In my mind, however, there is now a new and more convincing argument for
doing this incrementally. The "new" IPsec specs describe a bump-in-the-wire
IPsec mode (which was also subtly prevented in the "old" IPsec specs, because
it also leads to bad design problems). Suppose that my end host sends out:

  If we don't things incrementally, this is hard -- cryptographically
impossible if the bump-in-the-wire doesn't share the secret key with the end
host, actually.

  On the surface, an alternate solution is to remove the length field. However,
I believe that you'll find that the base header's next header type field has
the same problem if you have a bump-in-the-stack capable of inserting, for
example, ESP before AH (which used to be outlawed, and I think still is in the
IPv6 base spec). There might be other fields that become mutable if you take
this approach. Personally, I want as much of my packet protected as possible,
so I strongly admonish you to choose solutions that allow protection over
solutions that preclude it.

									-Craig

---

From: [email-masked]
Date: Tue, 11 May 1999 07:34:55 +0900

>IPv6 proper spec's description of chained header ordering. There's no

	RFC2460 chapter 4.1 has a diagram with "AH then ESP" ordering.
	However, there is a note that says "see RFC2406 for additional
	recomendations".
	So I figured that RFC2460 does not restrict the ordering.

itojun