Re: Is TS agreement necessary?

[Ramana Yarlagadda <ramana.yarlagadda@analog.com>]

At 12:55 PM 4/5/02 -0800, you 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?

If i understood correctly, Kalyan's mail,

It's just a point to point  link so there is no need to distingush the 
traffic. I mean
all the traffic leaving at that interface will be tunneld irrespective of 
the destiantion
beyond the other end of the tunnel.


>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.