[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
Responses inline...
On Thu, 18 May 2000, Stephen Kent wrote:
> Skip,
>
> > > Finally, in response to the security issues raised by obscuring the
> > > transit selectors from the ipsec machinery, the argument has been made
> > > that ppp provides all the necessary protections. However, this is not
> > > all that reassuring, and conjures up images of the left hand not knowing
> > > what the right hand is doing. Please elaborate a bit on how this
> > > mechanism provides comparable assurance to one where ipsec is employed
> > > alone.
> >
> >There are certainly two camps here and it almost becomes a religous
> >discussion.
> >My argument has always been that protecting L2TP with IPsec provides the same
> >level of security which our customers have today with their traditional
> >networks. If I have an IPsec SA set up between two peers (A and B), and the
> >traffic which is protected between us is A <-> B, UDP, port 1701,
> >1701 than the
> >only traffic which L2TP should *ever* see is traffic which arrived
> >from that SA.
> >Otherwise it should have been dropped when performing the inbound filtering
> >checks by IPsec. This statement requires no binding between L2TP and IPsec!
>
> I'm confused by this explanation. IPsec used with L2TP operates in
> transport mode, and it is the inner IP header (carried above L2TP)
> that determines the ultimate destination for the received packet.
> IPsec at the receiver does not see that header, because it is
> operating in transport mode. So, what IPsec filtering at which end do
> you assert is providing the check you cite above?
My point here was that PPP will only see traffic which was sent through the L2TP
tunnel and thus protected by IPsec. You are indeed correct that the inner IP
address obtained through IPCP is not looked at by IPsec. However once the
L2TP/PPP header has been removed, any inbound access lists tied to the PPP
interface may be applied to the IP packet. This effectively provides the same
level of security our customers have today with their leased lines and dial-up
connections, which they seem to be pretty happy with.
>
>
> >Now if I want to limit the type of traffic I allow my peer to send into my
> >network, I can apply filters to the PPP interface as has been
> >traditionally done
> >by our customers. They understand how this should be done and how
> >to audit this
> >as well. Additionally, at least for Cisco, they can get this filters on a per
> >user basis as part of their authorization information obtained from the AAA
> >server. The additional point which can be made is that the
> >traditional firewall
> >filters which can be applied to a PPP interface are much more robust than what
> >typically can be applied to IPsec packet filter statements.
>
> In what ways are the filters applied at the PPP interface "more
> robust?" For example, do these filters examine other parts of the
> packet?
Exactly. For instance, dscp, TCP syn, ack or fin, rst, psh, precedence/tos are
common filter fields in addition to src/dst addr, protocol, src/dst port. There
are some firewalls which can even look into the application information and
filter at that granularity.
-Skip
> > Steve
>
>
>
Follow-Ups:
References: