RE: Is TS agreement necessary?

["Sankar Ramamoorthi" <Sankar.Ramamoorthi@nexsi.com>]

 > -----Original Message-----
 > From: Mike Ditto [mailto:ford@incog.com]
 > Sent: Wednesday, April 03, 2002 12:01 PM
 > To: skelly@SonicWALL.com
 > Cc: ipsec@lists.tislabs.com
 > Subject: Re: Is TS agreement necessary?
 > 
 > 
 > "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.

abstract hint need to be standardized for interoperability,
since the hints are going to part of the negotiation.

Once done they could construe as a solution for ipsec traffic
segregeation for complex services (dynamic ports) - It is that
versus somehow conveying the dynamic selectors explicitly.

Explicitly conveying selector information provides the comforting
feeling that both peers know that each agree on exactly
what type of traffic is going to flow through the tunnel.

One problem I see with hints are

-  Both peers have to maintain faithful stateful inspection to keep track
    of the session (othewise 'session-unique' hint cannot be supported).
    It may or may not be always feasible. Also if the state of the session
    is not faithfully tracked, there is a possiblity for the receiver to
    incorrectly drop/accept the packets.

I do think however that IPsec solution scope should be defined

1) Should the scope be limited to a collection of layer4 information
    some of which may be dynamically determined?

2) Should IPsec granularity apply to layer5(and above information)
    such as URL, specific file-date?.. 

I think IPsec should not allow 2) - It would be useful
if the requirements can capture the scope explicitly when discussing
the requirements for dynamic ports.

 > 
 > 
 >  > 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 [=-
 > 
 >