[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows 2000 and Cicsco router interoperability
Chris Trobridge wrote:
>
> > From: W. Mark Townsley [mailto:townsley@cisco.com]
>
> > Chris Trobridge wrote:
> > >
> > > The point is that with an IPSEC SA traffic is only allowed
> > that matches the
> > > selector for that SA. In the access control case this
> > means you can enforce
> > > that anyone who connects via an IPSEC tunnel can only send
> > or receive
> > > datagrams associated with his client address. This
> > prevents him from
> > > spoofing other clients or hosts and from receiving traffic
> > not addressed to
> > > him.
> > >
> > > The moment you tunnel L2TP through an SA IPSEC loses its
> > ability to perform
> > > this filtering. Depending on the whether 'extra' work has
> > been done, once
> > > IPSEC processing has been completed the L2TP layer will not
> > know via which
> > > SA a datagram was received, allowing a client to spoof
> > other addresses.
> >
> > Why not?
> >
> > An SA protects an l2tp tunnel, which carries a PPP session, which
> > performed user authentication and authorization. Such authorization is
> > the basis for access control lists that can do a number of L3
> > checks on
> > the traffic which PPP framed. Here, a direct correlation
> > between a given
> > SA, the authenticated user, and finally her authorization for the
> > network.
>
> I suppose this all hangs on the binding between the SA, L2TP tunnel and the
> PPP session. I can't claim to be particularly familiar with L2TP, but
> comments made much earlier on list suggested that L2TP tunnels aren't
> tightly bound to IPSEC SAs. At the time no one countered this view. This
> was seen to be a weakness that might allow datagrams from one SA to
> delivered to an L2TP tunnel end point associated with a different SA.
Sorry I missed it.
I believe a basic assumption with L2TP and IPsec operating together
would be a tight coupling between the L2TP tunnel and IPsec SA. There is
an entire document whose purpose in life is to describe this coupling.
We will be sure to address this even more in the next version. What is
common sense to one person, is not to another. This is why we have peer
review.
>
> > ISPs and enterprises have been doing filter checks on incoming PPP
> > encapsulated data for years. The requirements for such have evolved
> > considerably over this time. I doubt that they want to toss this
> > functionality out the door and I cannot blame them.
>
> Given that PPP wasn't required or even present in the first place, I can't
Perhaps that has been one of the problems.
> see how you can make comments about throwing functionality out of the door!
> The basis this list has been working on is that IP datagrams are tunnelled
> from the client to the private network using tunnelling IPSEC-ESP.
The lines blur between IPsec and IPsra here.
As you say, what we are really talking about is the case where a client
is accessing a home network. Loosely adopted as the "secure remote
access" case. We have two choices. (1) Take a security protocol and try
to make it meet the myriad of remote access needs customers have today.
Or, (2) create a secure pipe over the Internet, treat that pipe as new
point to point media, and hook into the existing remote access
infrastructure that we already have. I have not been convinced that #2
is not the most viable option.
>
> Chris
References: