[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of client IDs
>
>
> Pyda,
>
> > > Dan pointed out that this is completely wrong. What I meant
> > > to say was "the semantics of an absent client ID *should be*
> > > anyone behind this trusted gatway ..."
> > >
> > > Bryan
> > >
> > It is very confusing to have such semantics. How is the peer node
> > to know all the subnets behind a VPN node? I would much rather
> > have the subnet (requiring security service) listed explicitly in
> > the ID payload.
>
> The peer node will have an SPD policy for outbound traffic, which
> will list the subnets. The current use of client ID by a receiving
> party, as I understand it, is to verify that the SA is suitable,
> and therefore there needs to be something to verify against -
> which is the SPD. I do not think that the client ID is intended to
> dynamically create an SPD entry. Now if you have already verified
> that your peer negotiator is trusted, as a result of an ISAKMP SA
> being established, further verification on each IPSEC SA may be
> redundant in many cases.
>
Trusting a peer node is different from figuring out whether a
packet should be tunneled to the peer or not. You cannot make
the assumption that your routing table will tell you whether or
not a packet should be tunneled to a peer, because you may not
be running routing protocols on top of the tunnels.
Hope this helps.
cheers,
suresh
References: