Re: Is TS agreement necessary?

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Fri, 5 Apr 2002, Stephen Kent wrote:

> At 12:55 PM -0800 4/5/02, Chinna N.R. Pellacuru wrote:
> >On Fri, 5 Apr 2002, Kalyan Bade wrote:
> >
> >>  > Infact the majority of what we call "site-to-site" deployments use GRE as
> >>  > a point-to-point virtual link, and use IPsec to protect the GRE tunnel.
> >>  > But, not everybody implements GRE, and this becomes an interoperability
> >>  > issue.
> >>  >
> >>  > I agree, it would be very useful to specify an interoperable way of having
> >>  > an IPsec tunnel be treated as a virtual point-to-point link, and not have
> >>  > to rely on GRE always. GRE has some more benefits like we can encapsulate
> >>  > all kinds of protocols in GRE, and not just IP.
> >>
> >>  I agree that it can done with GRE + IPsec transport mode. But, why in
> >>  the first place we have to do GRE when we can tunnel it directly through
> >>  IPsec (talking about IP traffic only). Is the RFC against it ? Am I
> >>  missing anything here ?
> >>
> >>  Thanks,
> >>  Kalyan.
> >>
> >
> >What does any,any mean in an SAD? How do you differentiate between any,any
> >to peer1, from any,any to peer2? If you use the same interface to go out
> >to peer1 and peer2, and the same SAD is being used for all the SAs on that
> >interface, when there is some data traffic, the traffic will hit all the
> >any,any selectors in the SAD. How do you decide which selector to pick,
> >and hence which peer to send the data to?
> >
> >By having an interoperable agreement of what an any,any selector means,
> >the IPsec peers can probably agree to create a virtual tunnel interface
> >for all any,any selectors, so that routing can differentiate between the
> >any,any tunnels, and route the traffic appropriately. Without making that
> >assumption, if we send an any,any to a peer, then that would probably
> >confuse the peer, and make it send ALL traffic to me (atleast all traffic
> >on that interface).
> >
> >Given that routing is way way more efficient and generally highly
> >optimized, compared to packet classification, we can also get a big jump
> >in performance. Eliminating packet classification requirement in the data
> >path brings along with it a lot of other benefits too. I have seen packet
> >classification being one of the biggest bottlenecks in many
> >implementations.
> >
> >     chinna
> >
> >chinna narasimha reddy pellacuru
> >s/w engineer
>
> In general, an any,any IP address pair would not work, since one must
> usually have a distinct SA per recipient (in the unicast context).
> But, in the case cited, a single link to a neighbor, and since SPD
> entries are per interface, there might not be a problem with this
> selector definition.
>
> Steve
>

I wasn't sure if a general agreement among IPsec implementations that
any,any always means a virutal link is sufficient, or it should be
specified in an RFC.

For example we already specify that if no Quick Mode ID payloads are sent,
then the default selector is all traffic from the local IPsec endpoint to
the remote IPsec endpoint.

    thanks,
    chinna

chinna narasimha reddy pellacuru
s/w engineer