[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[anonsec] SAB without connection latching



On Sun, Mar 19, 2006 at 11:11:45AM -0600, Michael Richardson wrote:
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>     Nicolas> On Fri, Feb 10, 2006 at 07:17:22PM -0500, Michael Richardson
>     Nicolas> wrote:
>     >> In a host-host BTNS system, with IPsec integrated into the stack and
>     >> connection latching, the TCP/UDP layer asks "please send this packet
>     >> with SA#xxx" and discovers either that the SA is gone, or if not gone,
>     >> then it goes out encrypted to RW A, which RW B can't decrypt.
> 
>     Nicolas> Better:
> 
>     Nicolas>  - transport, on output, says "please send this packet protected
>     Nicolas> by an SA that matches the characteristics of the SA originally
>     Nicolas> used for latching (this includes crypto algs AND peer IDs).
> 
>   It's really a lot of thinking to distribute around the place (and for
> connectionless procotols, it winds up in the application), and I'd rather let
> the key manager deal with determining what is "equal"

The ULP doesn't have to concern itself with the details of latching.

One way to architect this in software: for inbound packets let IPsec
pass packets up with a reference to the SA used to protect it, then let
ULPs call generic IPsec functions to either obtain a latch corresponding
to a given SA or determine whether a given SA matches a given latch; on
output ULPs should pass down a reference to a latch and IPsec just has
to find or establish an SA that matches the given latch.

For connectionless ULPs the application doesn't have to do the latching
as long as it can hold on to a "handle" for a particular 5-tuple and
corresponding latch.  In BSD socket terms, for sending a UDP datagram it
suffices to connect() a UDP socket before sending; for receiving you'd
have to do something where you accept() on UDP unconnected sockets to
get a "connected" UDP socket whenever a datagram comes in that doesn't
match the 5-tuple of an existing connected socket (or more).

>     Nicolas>  - the actual latch is constructed from the characteristics of
>     Nicolas> the SA that protected the first packet sent or received on the
>     Nicolas> given connection (e.g., the SYN packet, in the case of TCP).
> 
>   I thought a lot about doing that, but I decided simplify the life of the
> ULP.  I'm very concerned about BTNS work through NATs.

The ULP need not know the details of how to do this, see above.

All you need are generic IPsec functions of this form:

    sa2latch(sa#) -> latch

    sa_matches_latch_p(sa#, latch) -> true/false

plus let IPsec label incoming protected packets with the SA# used to
protect them and let ULPs label outgoing packets with a latch.

There may be other ways to design your implementation of connection
latching, of course.  My point here is that where ULPs are implemented
separately from layer 3 the ULPs need not know the details of IPsec
connection latching.

Nico
-- 


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.