Subject: [IPsec] RFC 4301 Appendix E on nested SAs

From: <[email-masked]>
Date: Mon, 4 Feb 2008 12:43:24 +0100

From the description in RFC 4301 Appendix E it is clear, that an
outbound packet from A to C is provided with two ESP headers before sent
on the wire.  It is also clear, that an inbound packet from B to A
with two ESP headers will be processed twice by IPsec before handed
to the application.  However, a packet arriving at A, purported sent
from C (ie with C as source address and A as destination address),
with only one ESP header, namely the ESP transport header, will be
processed only once by IPsec before handed to the application.
Thus the condition, that the packet ought to have had two ESP headers
is not checked.  If the ESP transport protection used by the
application has sufficient strength, no security breach is made.
However, if the ESP transport has low strength because it expects
the outer tunnel to provide adequate security on the wire between
A and B, then that adequate security is not mandated for inbound
packets.  Did I miss something?

Christian
_______________________________________________
IPsec mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Feb 2008 15:40:57 -0500

Christian,

The "simple" example on Appendix E does require that the packet from 
C be transport mode. If C is behind B, as indicated in the example, 
then traffic from C ought not be forwarded to A unless it is 
encapsulated in a tunnel from B to A. The example does not describe 
the SPD, SAD, or forwarding tables in B or C, so one cannot see this 
explicitly, but that is the intent.

Your messages says "... a packet arriving at A, purported[ly] sent
from C ..." An inbound packet with C as the source and with ESP 
integrity-only protection cannot be process correctly unless an SA 
(pair) has been established for this transport mode SA. In the course 
of establishing that SA, the IKE process in A verifies C's identity, 
so the packet really must be from C. If the packet is not from C, it 
will fail the integrity check and be discarded.  Hence the term 
"purported" seems inappropriate here.

So, the problem you cite could occur only IF C were not really behind 
B, OR IF B's SPD/SAD is in error (and C is behind B). If C is not 
really behind B, A cannot send any traffic to C, since the forwarding 
table is set to loop back all traffic from A to C, even if it is ESP 
traffic. Only when traffic is sent from A to B (inside the tunnel) is 
it allowed out. This applies to IKE traffic too, so no SA would be 
established between A and C.

The latter case (where C is behind B) is indicative of an error in 
SPD management at B. For example, B must terminate the inbound 
traffic from A (directed to C) received via a tunnel mode SA, and be 
willing to pass the resulting SP traffic to C, for the SA with C to 
be established, yet it must also allow outbound traffic from C to be 
bypassed to A.

You are right that we don't unilaterally protect against this sort of 
error in B's SPD, even though A's outbound traffic to C IS protected 
based on the nested SA configuration. One would have to add 
additional state to SAD entries to be able to tell if a 
Ipsec-protected packet that is valid when received within a tunnel 
was, in fact, delivered within the context of the tunnel.  Since 
support for nested SAs was made optional in 4301 (vs. mandatory in 
2301), it didn't seem reasonable to try to add the complexity that 
would be needed to enforce this constraint.  However it might be 
worthwhile noting this in the Appendix, e.g., via an errata.

Steve