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

RE: RFC 2401 section 5.2.1



To give the ipsec list some background for Francis's question:

Over on the mobile-ip list, we've been discussing how Mobile IPv6 should
interact with IPsec. A mobile node has both a Home Address and a Care-Of
Address. When the mobile node sends a packet, the source address in the IPv6
header is the Care-Of address and the Home Address is put in a Home Address
option. When the mobile node makes a security association or looks up
security policies, it uses its Home Address. (So when the mobile node moves
and gets a new Care-Of Address, it doesn't affect the security
associations.)

The current draft specifies that Binding Updates MUST be protected by AH and
that the Home Address option MUST appear in a destination options header
before the AH header and the Binding Update option MUST appear in a
destination options header after the AH header.

I've been arguing that this is too restrictive: instead Mobile IPv6 should
allow either AH or ESP to protect Binding Update option, depending on
policy. In the case of ESP, the Home Address option and the Binding Update
option would appear in a destination options header after the ESP header so
they are appropriately protected.

The question is, how will this interact on the receiver with the provisions
of RFC 2401 section 5.2.1. I've been arguing that the following
implementation style is possible:
- when the ESP header is processed, the destination address, SPI, and IPsec
protoocol are used to find the SA
- the receiver uses the SA to authenticate/decrypt
- finally we get to the point of the discussion:
section 5.2.1 requires that the packet's source address be checked against
the SA. In this case, we want to check the Home Address against the SA. But
the Home Address hasn't been seen yet - it's in a Home Address option in the
next header.
I think an implementation can either look ahead to find the Home Address
(much like you look ahead to find selectors in the transport header), *or*
an implementation can "lazy evaluate" this check, postponing it until after
the destination options header is processed.

Some questions:
a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP
is too restrictive?
b) Is the receiver processing that I'm proposing legitimate?
c) If Mobile IPv6 support is added to your IPsec implementation, would this
Home Address processing be unduly difficult for your implementation to
support?

Thanks,
Rich

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Sunday, November 19, 2000 10:49 AM
> To: ipsec@lists.tislabs.com
> Cc: Richard Draves
> Subject: RFC 2401 section 5.2.1
> 
> 
> In the inbound processing section 5.2.1 the RFC 2401 (IPsec 
> architecture)
> specifies:
>            1. Use the packet's destination address (outer IP header),
>               IPsec protocol, and SPI to look up the SA in 
> the SAD.  If
>               the SA lookup fails, drop the packet and log/report the
>               error.
> 
>            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.
>               ...
>               Do (1) and (2) for every IPsec header until a Transport
>               Protocol Header or an IP header that is NOT for this
>               system is encountered.  Keep track of what SAs have been
>               used and their order of application.
> 
> How this was intepreted in current implementations:
>  - is the packet's the source address checked in transport mode?
>  - is the packet's outer source address checked in destination mode?
>  - when are the checks done (before, ie. at the end of the lookup
>    routine, after, ie. after the processing of all IPsec headers)?
> If you know it, what is the rationale?
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: with the exception of KAME (no check), all open source 
> implementations
> I have seen are a bit paranoic, ie. they check all source addresses
> as soon as possible.
> 


Follow-Ups: