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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 29 Oct 2002 21:48:54 +0100

> 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.

=> Yes, I suspected that already, but I was assuming
that in Mike's proposal we do not a specfic proto
condition for things other than ICMP to the HA. So 
IPsec does not need to know the nxt header (i.e. we somehow
trigger IPsec from the MIPv6 code). I haven't 
looked into code to see how easily (or hard) this can be 
done. I'm mainly trying to find out how Mike's proposal
will really work. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 29 Oct 2002 22:27:20 +0100

> I think you need seperate SPD entries for MN-HA BU and HoTi
  > message, because the packet formats are different. that makes 
  > it 3 + 1(if payload needs to be protected) for each MN.
  > 

=> Are you referring to a HA implementing Mike's proposal?
If yes, then I don't think this is right. The whole point 
of his proposal is to _not_ rely on specific SPD
entries per MN. So 1 SPD entry will say "drop any packet
that includes MH and no IPsec". The rest will say: 

If src = MN_1 dst = HA proto = ICMP then use SA_1
If src = MN_2 dst = HA proto = ICMP then use SA_2
If src = MN_3 dst = HA proto = ICMP then use SA_3
If src = MN_4 dst = HA proto = ICMP then use SA_4
.
.
.
If src = MN_n dst = HA proto = ICMP then use SA_n

Obviously you need to distinguish those from other 
on-link ICMP traffic. 

So you need N+1 SPD entries I think

Hesham

---

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

> 
> > Mohan Parthasarathy wrote:
> >
> > 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
> 
> 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.
> 
Agreed. With this all packets between MN and HA will get protected.
What we want is just the MH traffic. If we do tunnel mode, then
we lose the outer IP header I guess.

-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: [email-masked]
Date: Tue, 29 Oct 2002 17:19:56 -0600

I agree with the proposal contained in Jari's email to resolve
this issue.

-Basavaraj

> -----Original Message-----
> Jari Arkko wrote: 
> 
> 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.
> 
>