Subject: RE: [mobile-ip] observation on the mip/ipsec draft + filtering

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 29 Oct 2002 13:05:04 -0800

> 
> "Hesham Soliman (EAB)" wrote:
>  
> > => No, I meant:
> > 
> >    IPv6 hdr (src = CoA, dst = HA)
> >    ESP hdr
> >    IPv6 hdr (src = HoA, dst = CN)
> >    Mobility Hdr
> >        HoTi
> > 
> > I'm also implicitly asking that the packet be tunnelled 
> outside IPsec, 
> > then IPsec applies ESP in transport mode.
> 
> as far as I know, this does not work. for a transport mode SA, 
> the protocol header (the next header) cannot be an IPv6 hdr. 
> IPsec chains through extension headers till it reaches a 
> transport protocol. but it does not include an IPv6 hdr.
> 
I thought this is what IP-in-IP transport mode was all about i.e
if you want to protect all traffic going through a tunnel using
a single SA, then this is how one can do it. When I negotiate the
Ipsec SA, can I not put IP-in-IP or IPv6-in-IPv6 in the protocol
field of the ID payload ? I know some implementations support this.

-mohan

> I am claiming IPsec wont be able to distinguish between
> 
> IPv6 hdr (src = CoA, dst = HA)
> IPv6 hdr (src = HoA, dst = CN)
> Mobility Hdr
>     HoTi
> 
> and
> 
> IPv6 hdr (src = CoA, dst = HA)
> IPv6 hdr (src = HoA, dst = CN)
> UDP hdr
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 29 Oct 2002 13:36:17 -0800

> Mohan Parthasarathy wrote:
>

sure this works.... but IPsec does not look beyond the IPv6 hdr.
for example it wont try to figure out if the inner IPv6 packet 
contains a Mobility Header or UDP.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Oct 2002 01:07:17 +0200

Folks,

This is turning out to be long debate. Given that I'd very much like to ship
draft 19 to IESG review etc this evening, I'd like to arrive at a preliminary
consensus now for the base I-D, and do some more work on the IPsec I-D during
its last call.

Specifically, I'd like to propose that the base draft adopts text that
does not tie our hands wrt to the location of the authorization test.
See the end of the e-mail for proposed text. Implementation freedom
that doesn't show up on the wire is good. This does not necessarily mean,
however, that we can freely choose N SAs in one end and M SAs on the other
end. We will find out later for sure if we can, and exactly how, use
just a single SA / SPD entry.

Secondly, what I believe we need now is a complete proposal for
Mike's approach before we can compare it to the currently adopted
approach. In particular, I believe we need security policy rules
and SAs as the results of IPsec policy decisions are often pretty
surprising unless all details are laid out. Vijay, Mike, and myself
have agreed to try to craft these details.

Finally, after an evaluation we may need to change the IPsec
I-D, and may even need to change the base I-D (this could perhaps
be done at the same time as comments from IESG are taken in account).

Jari
----
   In order to protect messages exchanged between the mobile node and the
   home agent with IPsec, appropriate security policy database entries
   must be created.  A mobile node must be prevented from using its
   security association to send a Binding Update on behalf of another
   mobile node using the same home agent.  This MUST be achieved by
   checking that the given home address has been used with the right
   security association. Such a check can be provided in IPsec
   processing, by having the security policy database entries
   unequivocally identify a single security association for any given
   home address and home agent. The check may also be provided as a part
   of Mobile IPv6 processing, if information about the used security
   association is available in there. In any case, it is necessary that
   the home address of the mobile node is visible in the Binding Updates
   and Acknowledgements. The home address is used in these packets as a
   source or destination, or in the Home Address Destination option or
   the type 2 routing header.

   As with all IPsec security associations in this specification, manual
   configuration of security associations MUST be supported. Automatic
   key management with IKE~\cite{rfc2409} MAY be supported. When dynamic
   keying is used, either the security policy database entries or the
   MIPv6 processing MUST unequivocally identify the IKE phase 1
   credentials which can be used to create security associations for a
   particular home address.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Oct 2002 20:41:24 -0800

Jari,

This sounds fine by me. We need to get the base draft out.

            jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: "Hesham Soliman (EAB)" <[email-masked]>; "Michael Thomas"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, October 29, 2002 3:07 PM
Subject: Re: [mobile-ip] observation on the mip/ipsec draft + filtering