Subject: Re: destination option update

From: Tim Hartrick <[email-masked]>
Date: Mon, 18 Dec 2000 11:07:31 -0800 (PST)

Erik,

> 
> > I don't know that the receiving application needs to know any of this.  It
> > merely needs to know that the appropriate security was applied by the system.
> > That would seem to be understood given that the application is receiving the
> > datagram.  If appropriate security wasn't applied the datagram should have
> > been discarded before it reached the application.
> 
> But the application might very well want to know what destination options
> were protected by ESP. The security checks will presumably only tell the
> application that, in the case of transport mode, that the tranport 
> header and data was protected.
> Thus the application can't tell if the destination options where covered
> by ESP or not using the APIs.
>

So the problem is that we have a node which is receiving control information
in destination options.  This control information must, at a minimum, be
authenticated using AH.  There are implementators that want to have the
processing of this control information in user space or in some kernel driver
which uses a kernel sockets API.  The current API has no way to inform the
application whether the extension header passed in ancillary data has been
authenticated.

Am I stating the problem correctly?

If so it seems like we could define a new ancillary data item which would
simply indicated whether a datagram did or did not have AH coverage.  We
could also define an additional ancillary data item which could mark
where in the extension headers the ESP header had been located.

For example, lets say we have a UDP datagram that looked like the following:

IPv6 header
Hop-by-hop options header
Destination options header
AH header
ESP header
<Encrypted>
Destination options header
UDP payload

Assuming that all the relevent IPV6_RECVxxx options had been enabled the
ancillary data would look like.

IPV6_HOPOPTS
IPV6_DSTOPTS
IPV6_AUTH
IPV6_ESP
IPV6_DSTOPTS

The IPV6_AUTH and IPV6_ESP ancillary data items would have zero length data.
They do nothing but mark where the respective headers are located in the
datagram.

Ugly with lots of overhead but given the requirement and the API we have
I don't see much in the way of choices.

Passing out the entire datagram might be easier except for the information
leaking that would occur because of the inclusion of the ESP and AH headers.

> > I think that the problem is on the send side for things like the home address
> > option and the encapsulation limit option.  In those cases the application
> > wants to send:
> > 
> > IP header
> > dstopt
> > upper layer
> > 
> > but the application wants the dstopt to be in the *non-fragmentable* part
> > of the datagram.  Given the current API and partially because of the
> > fragmentation algorithm in the IPv6 base specification that isn't possible.
> > In these cases the "application" may be a kernel tunneling driver or
> > something.
> > 
> > If we can enhance the API to allow the application to specify where it
> > wants the non-fragmentable part of the datagram to end that would fix the
> > problem(s) as I currently understand them.
> 
> Any suggestions on how to specify this on the send side?
> 

Heh....  Well given the limited fidelity of ancillary data there aren't a
lot of choices other than defining a new ancillary data type (IPV6_FRAGDSTOPTS
for example).  I haven't tried to think about other possibilities yet.

I would hope that if we define something like IPV6_FRAGDSTOPTS that we
could retire IPV6_RTHDRDSTOPTS since IPV6_RTHDRDSTOPTS, as I envision it,
is a subset of IPV6_FRAGDSTOPTS.

tim
--------------------------------------------------------------------
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: [email-masked] (Niels M�ller)
Date: 18 Dec 2000 22:57:19 +0100

> They do nothing but mark where the respective headers are located in the

To me it would make sense to have associated data that is the index of
the security association used (is that the right term? I'm not really
up to date on IPSEC terminology).

Would it make sense to use the same ancillary data on the sending
side, for applications that want full control of IPSEC and other
headers? I'm imagining an application that makes creative use of
nested ESP and source routing headers for hiding traffic.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 18 Dec 2000 17:05:21 -0500

> up to date on IPSEC terminology).

The actual spi value is not likely to be very useful to the
application (when key management is in use, it's a random number which
lasts as long as the sa does, and sa's are, in the long run,
ephemeral).  On the other hand, other metadata associated with the SA
would be (the authenticated peer identity, for one).

					- Bill

---

From: [email-masked] (Niels M�ller)
Date: 18 Dec 2000 23:36:21 +0100

Bill Sommerfeld <[email-masked]> writes:

> ephemeral).

It would be useful to the appliction if either (i) the application is
doing its own key management, and it installed a bunch of values into
the ipsec engine earlier, or (ii) there's some mechanism to map the
value to other useful information.

> On the other hand, other metadata associated with the SA

It still seems reasonable to provide a (short) index with the
ancillary data, and use some other mechanism to look up its
properties.

/Niels

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Dec 2000 15:11:32 +0100

In your previous mail you wrote:

=> I agree, the SPI is the useful key to metadata.

=> this should be managed by policies, not directly by the header API.

[email-masked]