Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ?

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 18 Mar 2002 17:25:41 +0100

Hi Viray,

Sorry for sending multiple mails.
 
> 
> > Hi Viray,
> > 
> > I agree that the conflict between piggybacking and 
> intermediate routers having IPSEC policies
> > that the MN's and the CN's not are aware off is 
> non-relevant in the current proposal. 
> 
> 
> good.
> 
Conceptually though, one aspect of the problem still stands in the sense
that by allowing the optional implementation of MIPv6 Control Messages in extension headers then they (MIPv6 control messages) cannot in general be protected by IPSEC policies 
set-up by the network (for some reason unknown to the user) over certain un-trusted links. 

Karen

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Mar 2002 00:14:01 -0800

> set-up by the network (for some reason unknown to the user) over certain un-trusted links. 

True. But as I said in an earlier mail, protection for Mobility Header
is end-to-end. I dont like an intermediate security gateway applying
some IPSec policy to the Mobility Header. Cant think of any scenario
where it would be useful.

Vijay

---

From: Markku Savela <[email-masked]>
Date: Tue, 19 Mar 2002 10:37:49 +0200

> where it would be useful.

Still, even if IPSEC and MIP6 are implemented on same host, it is bad
design if they have to be aware of each other.

I still propose the following solution

1) no new protocol numbers are assigned/requested

2) MIP6 information is passed in Destination options pretty much as
   original RFC/(or Draft?) specified

3) if MIP6 wants a specific IPSEC protection, then it does not
   piggyback existing streams, but instead "piggybacks" it's own
   generated UDP packets with a port that is designated for the
   purpose. (This is about the only difference to the original drafts:
   use UDP instead of "No Next Header")

Seems pretty simple and clean to me.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Mar 2002 16:19:29 +0100 (CET)

>    original RFC/(or Draft?) specified

Markku,

This would not allow the RR packets (HoT in particular) to be protected using
an IPsec tunnel between the HA and MN. Without this protection 
any nodes on that path, including anybody on the link the MN is visiting,
can send forge BUs for the MN.

Using a separate terminal payload type for the RR packets allows doing this
as well as using IPsec to protect home registrations.

   Erik

---

From: Markku Savela <[email-masked]>
Date: Tue, 19 Mar 2002 17:24:43 +0200

> as well as using IPsec to protect home registrations.

You left out my final point. This is the "separate terminal payload":

This is *FINAL* header, header such is needed. IPSEC can latch on the
selected well known port.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Mar 2002 16:31:09 +0100 (CET)

> > as well as using IPsec to protect home registrations. > 

I think this means that at least HoT always need to be carried in UDP
and also that BU/BAck used for home registrations need to be carried in UDP.

It would seem complex to be able to handle the same messages (BU/BAck) carried
both in UDP and in DO. What would we gain from this?

  Erik

---

From: Markku Savela <[email-masked]>
Date: Tue, 19 Mar 2002 17:32:26 +0200

> both in UDP and in DO. What would we gain from this?

No, UDP payload would be empty. It's always DO. Thats the beauty of it.