[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ECN: Tunnel/SA relationship
Markku Savela [SMTP:msa@anise.tte.vtt.fi] writes:
> I've one concern about this draft: it adds yet another
> unneeded binding between "tunnel" and SA, which is the
> wrong direction to go.
The basic reason for doing it that way is the desire
to be able to negotiate ECN support between tunnel endpoints;
this allows the tunnel ingress IPsec implementation to
determine that the tunnel egress IPsec implementation won't
discard congestion notifications before allowing the ECN
Capable Transport bit to be set in the outer header,
an important thing to know. In addition, there are
security implications to allowing this bit to be set
(it enables an adversary to erase congestion notifications),
and hence negotiating ECN support as part of setting
up a secured connection seems appropriate.
Negotiating ECN support as an SA attribute appears
to be the logical thing to do, especially as the
encapsulation mode (tunnel vs. transport) is already
negotiable as an SA attribute, and adding another
attribute creates the least in the way of new protocol
specification/mechanism. It is also the case that the
IPsec protocol mode (tunnel/transport/wildcard) is a
REQUIRED SAD field for implementations that cannot
always determine the mode to be used from context.
I would suggest that the decision to associate
encapsulation mode (tunnel vs. transport) with security
associations has been made, as reversing it would
require revisions to at least RFC 2401 and RFC 2407.
> In my implementation the tunnel wrapping is totally
> independent of the SA (SA really knows nothing about it),
> and I would prefer it to stay that way.
In that case you could choose not to implement the OPTIONAL
features in the IPsec/ECN draft -- the result is a minor change
to header processing at tunnel ingress to turn off ECN support.
> If this ECN is a good thing, I would think the information
> has a more natural place in the policy database, added to
> the tunnel specification.
Moving the indication of whether ECN is supported to the
SPD appears to remove the opportunity to negotiate ECN
support between the tunnel endpoints, which would be wrong (IMHO).
In addition, the header processing description in RFC 2401
makes it clear that the destination address for the outer
header comes from the SA. I'm not sure what was meant
by "tunnel specification", but I would think it includes
the destination address, since that determines where the
other end of the tunnel is.
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com
---------------------------------------------------
Follow-Ups: