[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKE transforms selection
According to the RFC 2408 (ISAKMP) section 4.2 at the end:
"The responder SHOULD retain the Proposal # field in the Proposal payload
and the Transform # field in each Transform payload of the selected
Proposal."
Does it mean that the reply should contain these number even though
there only one transform selected?
Does it apply for phase 1 and phase 2?
I've tried with a couple of implementations and they don't seem to act like
taht at least during phase 1.
If anyone could clarify me that it would be very useful.
Thanks!
Toni Barrera
-----Original Message-----
From: EXT Chris Trobridge [mailto:CTrobridge@baltimore.com]
Sent: 16. May 2000 11:12
To: CHINNA N.R. PELLACURU; Stephen Kent
Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
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.
However, I agree with Andrew: The packet filtering in IPSEC is rather
primitive and would be better provided via an IPSEC aware firewall.
Chris
> -----Original Message-----
> From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> Sent: 16 May 2000 07:31
> To: Stephen Kent
> Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com
> Subject: RE: Windows 2000 and Cicsco router interoperability
>
>
> Frankly, I don't understand what Andrew is trying to tell me.
> His bottom
> line was:
>
> "IMHO, the idea with the most technical merit is to remove packet
> filtering from IPsec and make the firewalls IPsec aware. (No, I'm not
> saying we should rewrite all the specs; that's just the
> *ideal* solution
> in my mind.)
>
> All clear now?" !!!
>
> Anyway, regarding access control:
>
> How many people beleive that the IPSec access control
> mechanism, is going
> to solve all our access control problems?
>
> If people beleived that IPSec access control mechanism solves
> all their
> access control problems, then I guess we wouldn't have a need
> to leverage
> the access control features that AAA provides. I have seen
> customers who
> are so fond of their AAA infrastructure, that they by-pass IKE
> authentication by using an equivalent of a global pre-shared key! and
> totally base their authentication on AAA authentication(and
> if you do this
> via xauth, that doesn't authenticate the DH exchange)! Let's
> face it, how
> many implementations support some form of global pre-shared key?
> Supposedly the customers wants this badly, and if we dont
> provide this,
> there are implementations that already provide this!
>
> To investigate the cryptographic binding between a packet
> that has been
> decapsulated, and to which the IPSec selector has to be applied, lets
> start by how the binding took form at the encapsulation side
> in the first
> place. At the encapsulation side, in the context on an IPSec
> implementaion, we have a selector based on IP Addresses, protocol and
> ports. Once a packet matches this selector, it is
> encapsulated, and that
> is all IPSec can truly enforce. Are you saying that this is
> all we need to
> enforce all kinds of access control requirements, and complex policies
> that any corporation can have?
>
> It's not just the access control folks that see IPSec as a nuance, but
> there are the Intrution Detection (ID) folks. If we do end to end
> security, IE from the client of some service to the server of that
> service, the ID folks don't like that. If we had an IPSec
> selector that
> says all traffic from any TCP high port to port 21 needs to be secured
> with a certain policy, it doesn't stop a legitimate user/a hacker who
> gained control of the system to do a simple TCP SYN flood
> attack. If this
> traffic was encrypted using IPSec, then there is no way that
> the Intrution
> Detection System (IDS), is going to detect this. So, these guys have a
> requirement that all IPSec tunnels should terminate on the
> perimeter of
> the network, so that these guys can do their job. I guess, someone is
> busy, out there trying to integrate ID into IPSec. xids? Then
> we can have
> xauth, xauthr, xacc, xids, mode config etc... and we can update these
> documents once every 6 months, to incorporate/support more and more
> features of these protocols. There are supposedly 6
> versions(revisions) of
> the draft that we already have, and different vendors support
> different
> versions. I leart today that we support version 3 on the cisco router.
> I guess we are just waiting for some customer to bang on our heads,
> demanding that they want version 6 because it has a feature x
> that version
> 3 cannot support.
>
> chinna
>
> On Tue, 16 May 2000, Stephen Kent wrote:
>
> > Chinna,
> >
> > Go back an reread the last few messages I have sent describing the
> > difference between what native IPsec does vs. what any
> standard says
> > about L2TP over IPsec re access control. That is the basis for my
> > comments and those of Andrew.
> >
> > Steve
> >
>
> chinna narasimha reddy pellacuru
> s/w engineer
>
>
>
>
>