[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC 2401 section 5.2.1
> From: EXT Richard Draves
> 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.
..or even later headers. Nothing says it must follow the IPSEC headers.
> 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?
Too restrictive. Decision should be on the policy writer, not hardcode in to
the implementations.
> 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?
Not after realizing that the "lazy evaluate" is the only one that really
works easily (at least for me). I had to go to "lazy evaluation" on my
implementation,
1) because after processing the IPSEC headers, there might be other
extension headers before the transport layer. => Cannot check policy because
skipping unknown extension headers is impossible [one cannot know the
structure of unknown extension headers. In my architecture, there is no
fixed set of supported headers. When new extension header is defined, the
existing stack can be made to support it just by writing a loadable handler
for it.]
2) what now happens is that my "IPSEC AH/ESP" handler gets called for each
AH and ESP, and also just before passing the packet to the upper layer. The
SA's of AH and ESP are remembered, and the policy check occurs at the call
that happens before upper layer. Thus, the next header in turn at that point
is always the upper layer header and easily looked at. The src and dst are
the current "effective" ones.
3) I presume that whatever logic is decided on Home Address option handling,
can be now fitted into this fairly easily.
On receive side, the processing is fairly deterministic. I'm more uncertain
about the outbound direction. How does the IPSEC required by Binding Update
activate (enable destination options in selectors -- I don't like that)?
What to do if IPSEC requirement of Binding Update and some other security
policy are in conflict (require different protection). Prevent "piggybacked"
Binding updates, send them always separate?
References: