Subject: (IPng 7510) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd

From: Richard Draves <[email-masked]>
Date: Wed, 12 May 1999 07:16:50 -0700

>   We always assemble other IPv6 extension headers before 
> doing IPsec. Then we
> insert the IPsec headers into their correct place. This means 
> that legitimate
> extension headers will be authenticated. When I say 
> incrementally, I mean that
> IPsec headers are inserted one at a time, not that the entire 
> packet is
> constructed this way -- it can't quite be, if you want to 
> have IPv6 extension
> headers authenticated correctly.
> 
>   This leads to a sort of obtuse way of doing things, but 
> it's the only
> generally workable way to do it. There exist extension 
> headers -- such as
> IPcomp -- for which it is not possible to determine the total 
> length without
> actually doing the majority of the header's processing. 
> That's doable with
> either approach, but both approaches require ugliness to handle it.

One concern with switching to this implementation model is that it would
seem to be less efficient. We have in mind optimizing the common-case header
construction for a TCP connection by having precomputed the headers as much
as possible. Now in the common case there is no other IPsec header between
the AH and IP headers, so it doesn't make a difference. But this points in
the direction of having the AH ICV computation use IP header length &
next-header values that reflect all the headers. Also on the receive side,
it's more work to remove intervening IPsec headers.

Another concern is that semantically it seems a little strange that AH
should be designed to protect the packet's integrity, especially including
proceeding extension headers, but then have preceeding IPsec headers not be
accounted for in any way.

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: Craig Metz <[email-masked]>
Date: Wed, 12 May 1999 16:15:34 -0400

>it's more work to remove intervening IPsec headers.

  We have been thinking a lot about efficiently building headers and I don't
believe that our technique inherently prevents it. (actually, the way our
current stuff was architected was designed to help it) One can still precompute
cached header templates, one for each header. Or you can tweak AH to skip over
preceding AH headers in the current layer of encapsulation, but that doesn't
work so well with some fast hash implementations.

>accounted for in any way.

  If you go down this path, it's not clear to me how the AHs will interact.
Do they always compute with the other AH's ICV fields zeroed? Or do they
compute with previous ICV fields zeroed and subsequent fields as computed?
Wouldn't that also imply an implementation's assembly order?

  AH is a little strange. But at the end of the day, it protects a lot of
things before the payload. As a trade-off, it doesn't protect a lot of other
things before the payload. Compare this to ESP's ICV, however, which protects
basically *nothing* before the payload. It might have been possible to define
AH such that it gave you more integrity protection, but it's too late now.

									-Craig

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 12 May 1999 16:52:26 -0400

I guess I'm one of the people convinced of Steve Bellovin's view of AH
as unnecessary.

The fields in the header which are protected by AH either (a) can be
changed en route and thus need to be excluded from the ICV, or (b) are
extremely likely to be constant for the duration of an SA, so it just
seems so much simpler to protect them by binding them to the SA (i.e.,
drop inbound packets if the header field(s) in question don't match
what the SA says it should contain).

						- Bill

---

From: Craig Metz <[email-masked]>
Date: Wed, 12 May 1999 16:54:43 -0400

>what the SA says it should contain).

  The latter is a solution that I believe would work. However, (a) that's just
not what the IPsec WG came up with (b) please, PLEASE don't open up old wounds
in that WG, it's taken so long to get to this point and (c) IKE is already far
too complex, adding this is not going to help.

									-Craig

---

From: Steve Deering <[email-masked]>
Date: Thu, 13 May 1999 09:53:30 -0700

At 4:52 PM -0400 5/12/99, Bill Sommerfeld wrote:
>changed en route and thus need to be excluded from the ICV,...

Bill,

The above sentence seems to say that the fields that change en-route
both are and are not protected by AH.  I presume that's not what you
meant.

>                                                        ...or (b) are

That's clearly false for the Payload Length field in the IPv6 header,
and of unknown truth value for yet-to-be-defined Hop-by-Hop options.

I've never seen Steve Bellovin's analysis that you refer to above.
Is there an emailmessage or a paper containing that analysis which
could be forwarded to this list?

Steve