[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is TS agreement necessary?



Hi Kalyan,

Thank you for picking up on this conversation.

Democracy and majority rule is fine, but we need a bill-of-rights too in
this forum. One of the first basic right should be that, all IPsec
implementations must not be forced to do inefficient things. Inefficient
things should be optional. This would avoid the seemingly majority of
"end-host" or "small systems" vendors from crushing the seemingly minority
of "large intermediate gateway" vendors.

It is no surprise that this particular requirement is coming from Juniper,
because the scalability and performance requirements of IPsec in general
are going through the roof, and we have to grapple with a very different
set of requirements than the "end-host" and "small systems"
implementations.

    thanks,
    chinna

On Fri, 5 Apr 2002, 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
>

chinna narasimha reddy pellacuru
s/w engineer