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

RE: RFC 2401 section 5.2.1



I'm cc'ing the mobile-ip list - I hope this works better than the last time
I tried to send a message to both ipsec & mobile-ip.

Our implementation uses the "lazy-evaluate" strategy, very much like you
describe and for the same reasons.

The security policy questions that you raise at the end of our message have
not yet been resolved satisfactorily, that I know of.

Thanks,
Rich

> -----Original Message-----
> From: Markku Savela [mailto:Markku.Savela@research.nokia.com]
> Sent: Monday, November 20, 2000 2:23 AM
> To: ipsec@lists.tislabs.com
> Subject: 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?
>