Date: Wed, 20 Dec 2000 07:31:31 -0800 (PST)
From: Michael Thomas <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I tend to doubt that sending the AH or ESP headers up the
| stack is especially useful.
I think what you mean is that applications are unlikely to find the
contents of those options (as they would be sent on the wire) useful
- and I'm not going to argue about that, I don't know nearly enough
about them.
However, something needs to inform the application that the header
was present - for applications that actually need to know, as distinct
from a "dumb" TCP application that just wants non authenticated packets,
or packets not correctly encrypted, dropped, and after that simply assumes
that the relevant option(s) appear correctly in all packets.
On easy way to do that is to leave the header in the (ancillary) data
passed up to the application - then it is obvious to the application
that the header was there - further, it is also obvious what other
headers were encrypted in the case of ESP (the ones that follow the
ESP header, and not the ones that precede it).
What is in the data part of those headers may well be totally irrelevant
to the application (I don't know) - if that is the case, then in the
header passed back to the application could be the information that the
application does want to know (or at least, that is one possible API).
That is ...
| 1) What security policy was applied in receiving the packet
| 2) What IPsec credentials were bound to #1
The stack could delete the original contents of the header, and
instead place that (kind of) information there.
Similarly, when sending, the application could pass its requirements
in the data segment of those headers, which the stack would use to
know where in the header sequence the header should be inserted, and
what security policies to apply to the packet - then it would replace
the application's supplied headers with ones formatted as they're
supposed to be transmitted over the wire.
Now I'm certainly not saying that that's the only reasonable API, not
even that it would be a good choice for the API - but it is one
possibility (on the assumption that the wire format content of the
headers isn't useful to the vast majority of those applications
which would be using this API at all).
Please, don't get stuck with the assumption that the interface between
the application and the stack needs to be an almost bit for bit
analog of the wire interface - the two of them are achieving quite
different objectives. The point of the API is to pass information to
the stack (and retrieve it from incoming packets) so that the stack can
then generate the packets that cause the protocol to effect the intent
of the application.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
