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

RE: Windows 2000 and Cicsco router interoperability

"allowing any authorized user to potentially spoof any other authorized
user"

Can you elaborate on how this is possible if you use L2TP/AAA/IPSec, and
how modeconfig/xauth prevents this?

I beleive that L2TP/AAA/IPSec can do anything that modeconfig/xauth does
with native IPSec, and does it only better(clean, simple, and modular).
And there are somethings that L2TP/IPSec can support that modeconfig/xauth
with native IPSec cannot, like multicast/multiprotocol traffic.

    chinna

On Mon, 15 May 2000, Andrew Krywaniuk wrote:

> Jan,
> 
> Allowing any authorized user to potentially spoof any other authorized user
> is an acceptable trade-off?!? Sure, it's better than allowing unauthorized
> users to spoof authorized users, but...
> 
> This doesn't mean you necessarily have to do firewalling in IPsec. I think
> Joe Touch's idea of doing IP in IP and passing the context information by
> reference has a lot of technical merit.
> 
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
> 
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> > Sent: Sunday, May 14, 2000 2:41 PM
> > To: Stephen Kent
> > Cc: ipsec@lists.tislabs.com
> > Subject: 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
> >
> >
> 
> 

chinna narasimha reddy pellacuru
s/w engineer
Follow-Ups: References: