Re: Is TS agreement necessary?

[Mike Ditto <ford@incog.com>]

"Scott G. Kelly" <skelly@SonicWALL.com> wrote:
 > Suppose, as you suggest, that we allowed negotiation of multiple SAs
 > between two peers without specifying TS values. Ultimately, there must
 > be *some* policy rule associated with each of these SAs since, as you
 > suggest, the point is to somehow segregate traffic between them. That
 > is, for a given SA, some traffic is allowed, and some is not. Please
 > elaborate upon how we determine which traffic is appropriate for each SA
 > once they are established.

OK.  At the time of sending a packet, the SA lookup would work basically
the same as it does currently; the SPD and SAD would determine which SA
is used.  I'm not proposing removing selectors from the SAD, I'm just
proposing that the selectors aren't sent explicitly in SA establishment.

When I initiate SA negotiation, I get to decide what goes in the
selectors on my end, just like current IKE implementations.  What's
different is how the selectors are set up for SAs that were requested by
my peer.  When my peer asks me to add an SA pair to my SAD, I mark the
SAs as "completely shared", "address unique" or "session unique" as my
peer requests.  If it's "completely shared" then I add a completely
wildcarded selector to the outbound SA.  If it's one of the "unique"
styles, I don't add any selectors and I will never use the outbound SA
until the peer has sent me some traffic on the inbound one.

Whenever I receive traffic on an inbound SA I add the corresponding
selectors to the matching outbound SA.  If the SA (pair) is "address
unique" I add to the outbound SA a destination address selector using
the packet's (inner) source address.  If the SA (pair) is "session
unique" then I add to the outbound SA a selector that describes my
concept of a session for that protocol (the easiest definition of
session for RFC2401-style implementations would be to use port numbers).
But the ends don't have to agree on the exact definition of a session.

An implementation is still able to use selectors on inbound SAs to
efficiently validate inbound traffic.  When an inbound packet doesn't
match the inbound SA's selectors, the SPD is checked and if the packet
is allowed, the appropriate selectors are added to the inbound and
outbound SAs.

The core idea of this proposal, the thing that makes interoperability
possible without agreement on the definition of a session, is that the
sender of each packet is free to choose between multiple equivalent SAs
however it sees convenient to implement, and the receiver accepts the
decision as long as the chosen SA matches the security parameters.  When
establishing SAs, the initiator gives an abstract hint to the responder
about the desired granularity of segregation.


 > As an aside, can you tell us why wildcard TS values do not satisfy your
 > requirements in the same way that omitting TS values would?

I think wildcard TS values would satisfy my requirements if I was
allowed to ignore any non-wildcard selectors sent to me, and if I
didn't want to implement traffic segregation.


					-=] Mike [=-