[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of client IDs
>
> Bryan Gleeson wrote:
> <trimmed...>
> >
> > I think that attempting to define a general purpose selector
> > protocol, which tells a responder exactly what packets the
> > initiator intends to send on an SA, is going to prove quite
> > difficult. For example I might want to encode in a message that
> > the SA was used to carry all traffic from subnets 1,2 & 3
> > to subnet 100, except ftp and telnet traffic (which receive
> > different treatment). In the absence of a fully general purpose
> > protocol whatever is defined will at best be a half-way house,
> > as it is today. It will always be a subset of the selector rules
> > that people wish to use.
>
> Yes, this is one of the remaining challenges for IPsec. Hopefully, it
> will be on the agenda.
I agree. Developing a specification format for SPD, as described in
the architecture document shouldnt be that hard, I suspect.
>
> > I think that applying a fine level of control about what packets get
> > transmitted onto an SA, is separate from conveying the filtering
> > information to the other end of the SA. A gateway could be separating
> > traffic out using an arbitrary amount of information from a packet
> > (e.g. looking at embedded URLs) and applying different security
> > policies. I'm assuming that there is no need for the receiver side
> > of an SA to view the allowed traffic on an SA with the same granularity
> > as the sender does. It may the same, or it may be coarser, all the way
> > down to allowing "any". Is this correct, or do both sides have to share
> > exactly the same view?
>
> 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.
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.
This would ensure that the SAin and SAout that were negotiated using IKE
are indeed used the way they are supposed to. Otherwise, tunneled packets
could be received on SAin, but sent out on SAout~, different from SAout.
cheers,
suresh
Follow-Ups:
References: