Subject: Re: [MOBILE-IP] RFC 2401 section 5.2.1

From: Richard Draves <[email-masked]>
Date: Mon, 20 Nov 2000 08:42:37 -0800

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:[email-masked]]
> Sent: Monday, November 20, 2000 2:23 AM
> To: [email-masked]
> 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?
>

---

From: Jean-Michel COMBES <[email-masked]>
Date: Tue, 21 Nov 2000 13:32:39 +0100

[email-masked] a écrit :

> >On Sun, 19 Nov 2000, Richard Draves wrote:
> >> a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP
> >> is too restrictive?
> >Strongly agree.  We'd like to see AH die entirely, and hence are opposed
> >to having any other standard demand its continued survival.
>
>         (again this holy war on AH)
>         I don't.  if you use transport mode IPsec heavily (unlike today's
>         VPN-only situation) how can you protect your header portion?

JMC :
You will use a Alternate Care-of Address Sub-Option, containing the CoA ( == IPv6
Hdr Src Addr), behind the DO-BU, but, IMO, this is a heavy solution : we have the
same thing twice ... In my point of view, DO-HA before AH/ESP plus AH mecanism is
the simplest solution.

>
>         since the introduction of IPsec there are so many protocols that rely
>         upon the use of IPsec to protect it.  I wonder what is their underlying
>         security model.
>
> itojun

JMC :
One thing I don't understand is what are the advantages to have the DO-HA behind
AH/ESP ? If it's a question of privacy (ie. hiding the MN location), I think that
doesn't resolve the problem unless to hide the Routing Header, which contains MN's
Home Address, coming from the Home Agent for the BAck.
On the other hand, having the DO-HA before the AH/ESP Hdr, will simplify
considerably filtering policy in FW (ie. filtering based on MN Home Address).

Regards.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Richard Draves <[email-masked]>
Date: Tue, 21 Nov 2000 10:37:17 -0800

fyi - some discussion from the ipsec list. From what I can tell, the
mobile-ip list rewrites message headers so we can't have a discussion
spanning both lists.

-----Original Message-----
From: Henry Spencer [mailto:[email-masked]]
Sent: Monday, November 20, 2000 11:30 AM
To: Richard Draves
Cc: [email-masked]; Francis Dupont
Subject: RE: RFC 2401 section 5.2.1

> b) Is the receiver processing that I'm proposing legitimate?

I'd say it is, with the caveat that I haven't worked with IPv6 enough yet
to really have a good feel for its header processing.

> c) If Mobile IPv6 support is added to your IPsec implementation, would
this
> Home Address processing be unduly difficult for your implementation to
> support?

FreeS/WAN is still far enough away from IPv6 support of any flavor that
it's hard to be sure, but it doesn't sound too bad.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Henry Spencer <[email-masked]>
Date: Tue, 28 Nov 2000 17:28:16 -0500

On Sun, 26 Nov 2000, Dan Harkins wrote:
> > seems to us that tunnel mode actually gives slightly higher security,
> > because it obscures whether the communication really *is* end-to-end...
>
> Obscured from whom? Don't transport mode and tunnel mode packets look
> identical to a passive evesdropper since the Next Header field is encrypted?

Unless the senders are doing clever things with padding etc., on most
links he can quickly tell whether tunneling is being done by inspecting
the low end of the packet-length distribution.

                                                          Henry Spencer
                                                       [email-masked]