Francis Dupont writes:
> Similarly for sending - the kernel interface might well ignore whatever the
> application stuck in one of these headers (frag, AH, ESP - perhaps others)
> but it could use the presence of such a header to indicate where it should
> place a header of equivalent type, constructed however it would have been
> constructed without this method of determining its location.
>
> => we agree.
I tend to doubt that sending the AH or ESP headers up the
stack is especially useful. What the application needs to
know that I can think of is:
1) What security policy was applied in receiving the packet
2) What IPsec credentials were bound to #1
The first one allows an application to know pertinent information
like whether or not the packet was encrypted/authenticated so
that it could perhaps reject unencrypted packets. More generally,
the application may want to place finer grain control based on
application layer knowledge than the SDP allows, or can express.
The second is to stop a forgery attack; if there is no way for
an application to query about an incoming packet/flow as to which
credentials were used, a trivial application layer forgery attack
could be mounted by just changing an application layer identifier
which is not bound to a cryptographic identity (eg, the From:
address in SMTP).
I'm pretty much at a loss as to what seeing the actual headers
would gain for run of the mill (read: non-packet sniffers :-)
applications.
Mike
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
