[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Windows 2000 and Cicsco router interoperability
In some people's minds, it's an acceptable trade-off, and others wil think
differently.
Personally, I don't see much difference with doing a check after decryption
and decapsulation, than doing it before. Yes, you may loose some context, but
so what.
You can either burden IKE and IPSEC with a whole bunch more mechanisms for
user-authentication, authorization, and accounting, thus making the protocols
even MORE complex (and thus less likely to be completely understood and
analyzed for weaknesses), OR you can combine two simple (relatively)
mechanisms, and combine them. In fact, it precisely because I DON'T want to
revisit these protocols, that I'm advocating l2tp+ipsec.
The loss of security you claim exists there, I don't see.
jan
On Sun, 14 May 2000, Stephen Kent wrote:
> At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote:
> >On Fri, 12 May 2000, Stephen Kent wrote:
> > > Shekhar,
> > >
> > > >I can understand the waste of bandwidth by L2TP.
> > > >But, can you please elaborate more on how does L2TP interfere
> > > >with the access controls?
> > >
> > > IPsec includes access controls analogous to those of a stateless,
> > > packet filtering firewall. The receiver knows the SA to which each
> > > packet is cryptographically bound, thus it can match the packet
> > > headers (selectors) against those that were negotiated for the SA in
> > > question. If a packet arrives over a tunnel mode SA, the receiving
> > > IPsec implementation checks the inner IP (and transport layer)
> > > header, while in transport mode, the outer IP header (and the inner
> > > transport header). When L2TP is used with IPsec, the L2TP spec calls
> > > for transport mode SAs, which means that only the outer IP header is
> > > checked. Thus the tunneled IP packet is not checked for access
> > > contorl purposes by IPsec.
> > >
> > > Once a packet leaves the IPsec environment, this binding to an SA is
> > > lost (unless some non-standard mechanisms are employed to maintain
> > > the binding). So the best that a separate firewall can do is to match
> > > the packet against its filter list to see if it matches ANY filter
> > > rule. This is much less secure.
> > >
> >But no less usefull.
> >
> >jan
> > --
> >Jan Vilhuber vilhuber@cisco.com
> >Cisco Systems, San Jose (408) 527-0847
>
> If reduced security in a context that focuses on security (else why
> use IPsec at all?) is considered equivalent, then maybe we all need
> to revisit the goals of these protocols.
>
> Steve
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: