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

Re: use of client IDs

> 
> Pyda Srisuresh wrote:
> <trimmed...>
> > > Policy is a local matter. Gateways with differing policies may or may
> > > not communicate, depending upon the intersection of their policy sets.
> > >
> > 
> > Well, not really.
> > 
> > A VPN node has to use policies to determine which SA to send a packet out
> > on. When a packet is received on an SA (say, SAin), it will detunnel the
> > packet and send to the appropriate target host. When a response comes back
> > from the target host, the VPN node has to figure out which of the many SAs
> > to use for sending the packet back to peer-VPN node (There may be multiple
> > SAs between the same peering nodes). If there is no policy mismatch between
> > the peering nodes, this would be no problem in selecting the right SA.
> > Otherwise, there is a potential for you to send the packets on the wrong
> > SA.
> 
> You missed the point: if their policies don't intersect, *there won't be
> a SA*.

Let me expand a bit on what I am trying to say here. 

   It is not good enough for policies to intersect. They must match. 
   Alternately, where only a subset of a policy matches, the receiving 
   node must be prepared to split the original policy into one that
   has a match and one that doesnt have match. That could get messy.

   Another subtle item is the sequencing of policies on either end.
   It is quite possible to have SAs established with matching policies 
   and still have the packets blackholed, because the policy ordering 
   is not the same on both ends. 

   When  a data packet that must be tunneled securely, arrives on a VPN 
   node; the VPN node will simply search through its policies and will 
   apply the first policy (and its outbound SA) that matches. The 
   receiving peer could be receiving the data packet on a lesser 
   desirable policy than was intended at the time of negotiation. 

   A simple example would be when VPNa and VPN b have the following
   ordering of policies. 

   VPNa:

      1. Send and receive TCP packets with VPNb using 3DES encryption.
      2. Send and receive UDP packets with VPNb using DES encryption.
      3. Send and receive all IP packets with VPNb using NULL encryption.

   VPNb:

      1. Send and receive all IP packets with VPNb using NULL encryption.
      2. Send and receive TCP packets with VPNb using 3DES encryption.
      3. Send and receive UDP packets with VPNb using DES encryption.

In summary, what I am trying to say is that the current scheme of things
require the peer nodes to have matching policies in exactly the same 
order. Otherwise, bad things could happen.

> 
> > I believe, the intent of exchanging policies is so that a VPN node could
> > use the policy to correctly determine which SA to use on the way out.
> 
> Policies are not exchanged, at least not in the current implementations,
> as far as I know. Proposals which result from policy are exchanged.
> 

As far as I can tell, policies are exchanged between peer nodes. Without
that, you cannot be certain peer nodes will utlize the right SAs for
secure data transmission. While policies may be determined locally, they 
need to be exchanged with the appropriate peer nodes. 

Hope this helps.


cheers,
suresh
Follow-Ups: References: