[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ECN: Tunnel/SA relationship
>> 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.
I did a "per-node" configuration for ECN friendliness, rather than
per-SA, for our implementation (see below).
Is it worth doing it or is it harmful?
Adding an attribute to SA (and modifying IKE daemon) looks too much
for me, and it seems to me that per-host configuration solves most
of the cases.
If it is harmful to ECN people, I'll be removing this code from ours.
itojun@kame.net
---
4.5 ECN consideration on IPsec tunnels
KAME IPsec implements ECN-friendly IPsec tunnel, described in
draft-ipsec-ecn-00.txt.
Normal IPsec tunnel is described in RFC2401. On encapsulation,
IPv4 TOS field (or, IPv6 flowinfo field) will be copied from inner
IP header to outer IP header. On decapsulation outer IP header
will be simply dropped. The decapsulation rule is not compatible
with ECN, since ECN bit on the outer IP TOS/flowinfo field will be
lost.
To make IPsec tunnel ECN-friendly, we should modify encapsulation
and decapsulation procedure. This is described in
http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, chapter 3.
KAME IPsec tunnel implementation can give you three behaviors, by setting
net.inet.ipsec.ecn (or net.inet6.ipsec6.ecn) to some value:
- RFC2401: no consideration for ECN (sysctl value -1)
- ECN forbidden (sysctl value 0)
- ECN allowed (sysctl value 1)
The behavior is summarized as follows (see source code for more detail):
encapsulate decapsulate
--- ---
RFC2401 copy all TOS bits drop TOS bits on outer
from inner to outer. (use inner TOS bits as is)
ECN forbidden copy TOS bits except for ECN drop TOS bits on outer
(masked with 0xfc) from inner (use inner TOS bits as is)
to outer. set ECN bits to 0.
ECN allowed copy TOS bits except for ECN use inner TOS bits with some
CE (masked with 0xfe) from change. if outer ECN CE bit
inner to outer. is 1, enable ECN CE bit on
set ECN CE bit to 0. the inner.
General strategy for configuration is as follows:
- if both IPsec tunnel endpoint are capable of ECN-friendly behavior,
you'd better configure both end to "ECN allowed" (sysctl value 1).
- if the other end is very strict about TOS bit, use "RFC2401"
(sysctl value -1).
- in other cases, use "ECN forbidden" (sysctl value 0).
The default behavior is "ECN forbidden" (sysctl value 0).
For more information, please refer to:
http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt
RFC2481 (Explicit Congestion Notification)
KAME sys/netinet6/{ah,esp}_input.c
(Thanks goes to Kenjiro Cho <kjc@csl.sony.co.jp> for detailed analysis)
References: