[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ID payloads semantics for phase 2 SAs
Jeff,
I really don't see a problem with the infrastructure of the current set of
IP Security protocols here, it is a matter of modifying the local policy to
get the correct behaviour. However, if you want to avoid problems like
this, you may want to look at a recent discussion about decorrelating
policy which removes the need for total ordering. Matt Condell recently
sent around an e-mail describing a decorrelation algorithm that you might
find interesting. I have no idea if this is going to be incorporated into
any future drafts or not, but I'd certainly like to see it.
Steve
====Precise. Making your ideas an embedded reality====
Steve Robinson
Software Designer
Precise Software Technologies Inc.
301 Moodie Drive, Suite 308
Nepean, Ontario, Canada K2H 9C4
Telephone: 613-596-2251 x237
Facsimile: 613-596-6713
http://www.psti.com/
Unless otherwise expressly stated, this message does not create or vary any
contractual relationship between you and Precise Software Technologies Inc.
or any of its affiliates. The contents of this e-mail may be confidential
and if you have received it in error, please delete it from your system,
destroy any hard copies and telephone the above number. Incoming emails to
Precise may be subject to monitoring other than by the addressee.
jeff
<jeff@allegrosys.co To: ipsec@lists.tislabs.com
m> cc:
Sent by: Subject: ID payloads semantics for phase 2 SAs
owner-ipsec@lists.t
islabs.com
06/22/01 07:07 PM
I'm wondering what are the semantics of the ID payloads
in phase 2. Look at this example:
[Host1 (206.1.1.1)] ====== [Host2 (206.1.1.2)]
Suppose that Host1 has SPD (in priority order):
send-clear udp any
send-crypt ip-dst 206.1.1.2
;; Host1 will send all UDP in the clear, and
;; any non-UDP traffic to 206.1.1.2 will get
;; encrypted
Suppose that Host2 has SPD (in priority order):
send-clear udp 500
send-crypt ip-dst 206.1.1.1
;; Host2 will send all UDP port 500 traffic in
;; the clear and all non-UDP/500 traffic will to
;; 206.1.1.1 will get encrypted
The ID payloads are sent on the wire, and the
IPSec SAs get setup. These ID payloads don't
(cannot) express the actual set of traffic that
will be protected.
Traffic starts, Host2 initiates a top-secret
transaction using UDP port 2000, and Host1 sends
the top-secret response in the clear!
Is this expected behavior? Shouldn't the ID
payloads give you some expectation of protection?
With this behavior, all the ID payload really
says is that some classes of traffic won't make it
into the tunnel, but there is no guarentee that
*any* class of traffic will!
Should IKE at some point be enhanced so that
ID payloads can be chained to express more complex
classes of traffic?
Sorry if this has been mulled over before,
Jeff