Re: Another field for traffic selector?

["sankar ramamoorthi" <sankar@speakeasy.net>]

----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>
To: <ipsec@lists.tislabs.com>
Sent: Wednesday, March 12, 2003 4:20 PM
Subject: RE: Another field for traffic selector?


> Comments on various people's comments, if I think the above doesn't
> answer the comments...
>
> 1) packets do not need to be verified as coming on a particular virtual
> net. Assuming there is end-to-end IPsec as well as firewall-to-firewall,
> packets would just get lost if misrouted, since the key wouldn't work.
> If there is only firewall-to-firewall IPsec, then you were trusted
> the firewalls anyway, and the firewalls can (as they could without
> VPN-IDs) modify IP addresses, route between the VPNs, etc.

This is how I understood the VPN-ID usage. What I was trying to point out
that this IKEV1 went into a lot of effort to ensure negotiated traffic
selector parameters are verified for each packet. This issue comes up
periodically. There was a long thread last year questioning the need for TS.
One of the points that was emphasized repeatedly was the access control
features of ipsec.

If we now make part of the negotiated traffic selector (VPN-ID) to be not
sent on the wire but implicitly trust the peer to send the data through the
right SA, are we loosening the access control mechanisms in ipsec? What does
it imply?

>
> 2) Why does it need to go into IKEv2?...because otherwise there's
> no way to route the packets, if the IP addresses in the customer
> nets overlap.
>
> Radia
>
>
>