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

From: Richard Draves <[email-masked]>
Date: Mon, 10 May 1999 17:40:52 -0700

Several comments on the recent discussion...

First, RFC 2401 (the architecture spec) is pretty clear about combinations
of security associations. Section 4.5 begins:
   This section describes four examples of combinations of security
   associations that MUST be supported by compliant IPsec hosts or
   security gateways.  Additional combinations of AH and/or ESP in
   tunnel and/or transport modes MAY be supported at the discretion of
   the implementor.  Compliant implementations MUST be capable of
   generating these four combinations and on receipt, of processing
   them, but SHOULD be able to receive and process any combination.  The
   diagrams and text below describe the basic cases. ...

So an implementation may support an AH-AH combination. KAME & MSR IPv6
choose to support this combination, out of a desire for orthogonality.

Second, there's the question of how to calculate the AH authentication data
(the ICV). The ICV calculation is unusual because it looks "back" to the
preceding IP header. If header construction is done "incrementally" then any
extension headers that are added later, after the ICV calculation, will not
be authenticated. This is generally not good.

The jumbogram case is an example. You want the jumbogram option to be
authenticated. So the packet should be constructed complete with the
hop-by-hop header before performing the ICV calculation.

Any headers that *are* added after ICV calculation should be removed on the
receive side before ICV verification. Fragmentation is an example. The whole
packet is protected with an AH header, then it is fragmented. Fragment
headers are inserted, but they are removed by reassembly before the AH
header is processed by the receiver.

Although the spec allows it, it's relatively difficult to create a
bump-in-the-wire implementation that supports transport mode. For example,
it needs to reassemble fragments, apply transport-mode associations, then
refragment. Yuck.

Suppose a bump-in-the-wire (or bump-in-the-stack) implementation is
inserting a transport-mode AH header (call it AH2), and the stack proper has
already inserted a transport-mode AH header (call it AH1). I don't think we
should expect this to work. AH1 protects the integrity of the packet. The
later addition of AH2 violates the packet's integrity. When the packet is
received, the AH1 ICV verification *should* fail.

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: Mon, 10 May 1999 20:54:03 -0400

>choose to support this combination, out of a desire for orthogonality.

  As does my code, same reason.

>If header construction is done "incrementally" then any

  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.

  Adding extension headers as a bump in the wire probably should be considered
invalid. It used to be, and for good reasons.

									-Craig

---

From: [email-masked]
Date: Tue, 11 May 1999 10:16:49 +0900

>headers authenticated correctly.

	Same for KAME.  We do like this:

	Beginning of ip6_output:
		IPv6 payload	(options are kept in pcb)
	Paste options as needed, in documented order.  rthdr needs to be 
	updated later.
		IPv6 hbh dst1 rthdr dest2 payload
	Insert IPsec headers as needed, one by one, updating header length
	field (and, in some cases, insert jumbo payload option).  Of course
	we encrypt the part after esp.
		IPv6 hbh dst1 rthdr [esp|ah]* dest2 payload
	Modify rthdr properly, and send the packet out.

itojun