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 PROTECTED]
--------------------------------------------------------------------
