Re: Is TS agreement necessary?

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

On Fri, 5 Apr 2002, Kalyan Bade wrote:

> "Chinna N.R. Pellacuru" wrote:
> >
> > On Fri, 5 Apr 2002, Kalyan Bade wrote:
> >
> > > > 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).
> > >
> > > Agreed. This problem arises only when I have an SPD per interface.
> >
> > The problem actually gets worse if you don't have an SPD per physical
> > interface. If you had only one SPD on the box, then all your any,any
> > selectors will now exist in the single SPD, and hence causing a bigger
> > problem.
> >
> > From
> > > a router customer point of view, the customer wants to see IPsec
> > > tunneling similar to a GRE tunneling and let the forwarding table decide
> > > what packets should be forwarded to IPsec tunnel. Here, the forwarding
> > > table is the SPD for me (a global one), not a per interface SPD.
> >
> > The routing table effectively becomes the SPD in a sense, or in other
> > words, it decides what selector(virtual IPsec tunnel) needs to be used,
> > based on the routing (network topology) information. There would be only
> > one SA in the SAD of the virtual IPsec tunnel interface, which is any,any
> > selector, and you won't need to have an SAD on the actual physical
> > interface that data will ultimately go through.
>
> Exactly.
>
> > On the actual physical interface, you will still have an SPD,
>
> We are talking about a global SPD here, not a per interface SPD.
>
> > moment someone sends you a any,any selector, we should not include that
> > SA into the SAD of the physical interface, but instead create a virtual
> > interface for that IPsec tunnel, with tunnel endpoints as the local IPsec
> > endpoint and remote IPsec endpoint, and have a single SA with the selector
> > any,any on that virtual IPsec tunnel.
> >
> > Now, when routing decides to forward any outgoing traffic onto any of the
> > IPsec virtual tunnels, the single SA that is on the IPsec virtual tunnel
> > is applied to all that traffic.
>
> Exactly. Isn't it simpler solution (atleast from a router point of view)
> ?
>
> Thanks,
> Kalyan.
>

Yes, along with the simplicity, we also get performance, because we punt
the packet classification, and access control problem to the firewall
folks. It's their problem anyway, and they do a very good job at that.
That is their sole purpose of existance. Atleast IPsec won't be the
bottleneck anymore :-)

Otherwise if we do limited access control in IPsec, and people generally
want more, it is redundant and hence the packet is subjected to packet
classification multiple times, in it's life through the box. Once for the
incoming firewall inspect, once by IPsec, and one for the outgoing
firewall inspect, and it has generally been a big problem of coordinating
all these inspection policies with the IPsec policies.

    chinna

chinna narasimha reddy pellacuru
s/w engineer