[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RFC 2401 section 5.2.1



> Henry Spencer writes:
>  > Perhaps.  But the existence of protocols which depend on 
> it should not be
>  > advanced as a reason, unless it is first demonstrated that 
> those protocols
>  > fundamentally need AH and could not work with ESP.
> 
>    The canonical example I keep hearing about is that
>    ip6 binding updates require AH and can't live
>    with ESP. I'm not sure I buy that, and I'm not
>    sure whether there isn't tail-wagging-dog
>    going on there, but until that gets sorted out,
>    AH at least has one vocal set of partisans.

What started this whole thread was my contention that Mobile IPv6 Binding
Updates *can* be protected by ESP, and Francis wanting to check the
interpretation of RFC 2401 section 5.2.1 because it is relevant.

The issue is this text:

           2. Use the SA found in (1) to do the IPsec processing, e.g.,
              authenticate and decrypt.  This step includes matching the
              packet's (Inner Header if tunneled) selectors to the
              selectors in the SA.  Local policy determines the
              specificity of the SA selectors (single value, list,
              range, wildcard).  In general, a packet's source address
              MUST match the SA selector value.  However, an ICMP packet
              received on a tunnel mode SA may have a source address

The text reads as if the comparison of the packet source address and the SA
selector value happens immediately, before you proceed to look at any
headers after/inside the IPsec header. Whereas to support Mobile IPv6, you
want to delay the selector checks (against the SA as well as against the
SPD) until you've reached the transport header (or are otherwise going to
actually do something with the packet) - so that a Home Address option that
follows the IPsec header can be processed before the source address check.

Rich