[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] Improvement for IPsec: Better PMTUD, ICMP Processing,and signalling in general!?
Warning: The following is only my take on the current situation. I could be wrong. Or I could be right but politically incorrect.
ESP and AH SAs are defined as unidirectional because one can imagine circumstances where unidirectional SAs would be desirable, people were not willing to ignore that obscure case, and it seemed easier to deal with the awkwardness to two unidirectional SAs in the common case than to specify both unidirectional and bidirectional ESP and AH SAs (including all the ways in which they were different).
The "most commonly cited" cases for unidirectional SAs are for multicast, but I'm pretty sure there are others.
IKE SAs are bidirectional, and all ESP and AH SAs negotiated by IKE are negotiated in pairs. In IKEv2, those paired SAs remain semantically paired after creation. They must be closed together, for example. This may have also been true in IKEv1 (it's hard to tell from the spec). Some other keying protocol would be necessary for setting up multicast or unidirectional SAs.
So I believe that for nodes using IKEv2 for keying, the fact that ESP and AH SAs are unidirectional is matter of specification only. An implementation could "think" of them as paired without changing any bits on the wire. I would expect most implementations to do just that.
--Charlie
-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Lars Völker
Sent: Thursday, June 17, 2004 1:49 AM
To: 'Karen Seo'; 'Stephen Kent'
Cc: ipsec@ietf.org
Subject: [Ipsec] Improvement for IPsec: Better PMTUD, ICMP Processing,and signalling in general!?
Abstract: Several problems of IPsec are caused by the concept of unicast
SAs. With very small and compatible changes major improvements for inband
PMTUD, ICMP processing, and others might be achieved.
While implementing the IPsec standard (and a few modifications) I was
wondering why the IPsec standard described SA as being unicast but did not
provide a simple way to form bidirectional combinations while SAs are mostly
used in pairs.
With IPsec secure bidirectional connections are possible as long as two
matching SAs are created (outgoing and incoming). Problems just arise in
error conditions and when other means for signalling are used. In-band PMTUD
and Signalling Messages are examples.
The changes to IPsec would only include a new field in the SA structure to
point to the inverse SA, the PF_KEY API would get a new function to set up
the relationship, and the Key Exchange daemons and setkey Utilities could
use this PF_KEY function to set up the new field in the SAD.
Cons:
Some small changes are required iff additional features are wanted. The
changes are rather small and could be initially marked as MAY. No Flag Day!
The changes to Key Exchange daemons and Utilities are also very small since
SAs are setup in pairs in almost all cases anyway and in other cases the new
SA field does not need to be set.
A minimal set of signalling message needs to be handled by IPsec since the
key exchange daemon can not handle these.
Pros:
The small changes would give us a foundation to solve some major
implementation problems and close some of the possible bugs in
implementations. A working PMTUD would allow us to fragment before
protecting packets without the risk of getting the packet discarded in
nested tunnel scenarios. Signalling messages can be sent back in a secure
manner (no data leakage) and it's obvious for the receiver for which SA the
message is meant.
I am looking forward to your replies
Lars
--
Lars Völker
Institute of Telematics, University of Karlsruhe, Germany
Phone: +49 721 608 6397
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec