Subject: RE: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking)

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 4 Mar 2002 11:40:22 +0100

Hi Vijay

> Jari Malinen and I had sent a writeup to the design team describing
> when you can piggyback and when you cant, when you have IPSec
> turned on. We concluded that piggybacking is possible only in two
> cases out of four. Heres a table from the writeup
> 
>            Table 1. Piggybacking with IPsec
> 
> 	  IPSec policy for    IPSec policy
>            Mobility header     for Payload    Can piggyback
>       1.       no                 no              yes
>       2.       no                 yes             yes
>       3.       yes                no              no
>       4.       yes                yes             no
> 
> 
>  From the table, the sender does not piggyback at all whenever the
> mobility extension header has an IPSec policy.
> 
> For handling the first two cases, there is no need for any change
> to RFC 2401 or the existing IPSec implementations. Please let me
> know if I am wrong.
> 
> 

I do not think that the assumption that the sender is able to determine
the presence of IPSec policies is valid:

It can probably (by interacting with its IPSec module) determine the presence of IPSec policies on its own link, 
and it can perhaps also (by asking the peer) determine whether there are IPsec policies on the
peers link - But what if some intermediate routers have IPSec policies anchored on the payload which
the sender has no knowledge of (e.g. protected tunnels over insecure networks 
for certain kind of communications). Then the MH can result in these packets not being
properly processed (since the IPSec selector will target the MH and not the payload)

I would therefore say that even in 1., piggybacking in general is not possible.

BR,
Karen Egede Nielsen
Ericsson Telebit

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 13:27:58 +0200

"Karen E Nielsen (TED)" wrote:

> It can probably (by interacting with its IPSec module)
> determine the presence of IPSec policies on its own link,
> and it can perhaps also (by asking the peer) determine
> whether there are IPsec policies on the peers link - But
> what if some intermediate routers have IPSec policies
> anchored on the payload which the sender has no knowledge
> of (e.g. protected tunnels over insecure networks
> for certain kind of communications). Then the MH can
> result in these packets not being properly processed
> (since the IPSec selector will target the MH and not
> the payload)

This is an excellent point, and a point that at least I
have forgotten in this discussion. Unless someone sees
a way around this, we have then only three alternatives,
(1) give up piggybacking altogether, (2) allow piggybacking
only in messages that never need to be protected specially
by IPsec, or (3) change IPsec. Since changing IPsec
particularly on possibly already existing nodes that
appear between two MIPv6 hosts is probably out of the
question we are left with alternatives 1 and 2.

Alternative 2 is troublesome because there seems to
be folks who want to use IPsec-only for BU protection;
I'd be happy with saying that you'll have to run RR or
CGA for every BU. Also, since the Home Agent needs
to protect RR messages as they pass through it, making
RR messages invisible to IPsec policies would mean
running IPsec on all traffic between the HA and the MN.

So it looks like what we are left with is alternative 1.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Mar 2002 10:22:57 -0800

hi Karen,

The answer is very simple.

> I would therefore say that even in 1., piggybacking in general is not possible.

The current proposal is to use both a final and non-final Mobility
Header (MH). In Case 1, the non-final MH is used (because it is 
being piggybacked). And when the intermediate router (SG) receives
this packet, it treats the MH as a normal extension header, scans
past it, finds the payload and applies the appropriate IPSec
policy. This should work.

You were right, but the problem exists with the earlier proposal. 
Not with the most current piggybacking proposal which has both
a final and non-final MH.

regards
Vijay

---

From: Markku Savela <[email-masked]>
Date: Fri, 15 Mar 2002 21:57:50 +0200

> From: Vijay Devarapalli <[email-masked]>

> policy. This should work.

Do I understand this correct? The solution calls "burning" two
protocol numbers: one for new intermediate header and one for the
final?

At least, could save one by sticking to the original destination
options when intermediate.

If you are truly contemplating about creating a totally new extension
header number, you need to remember that currently deployed IPv6
stacks only know about following extension headers

  - Hop-by-hop header
  - routing header
  - destination options
  - ah, esp

If they scan the packet and run into *anything* else, they don't
recognize it as extension header. They either drop the packet or
assume it is upper layer protocol. They definitely not cannot skip
unknown headers.

     IPsec policy for    IPsec policy
     Mobility Message    for Payload    Can piggyback
 1.       no                 no              yes
 2.       no                 yes             yes
 3.       yes                no              no
 4.       yes                yes             no

Basicly, this table reduces

    Want IPsec for
   Mobility Message?
  1.       no     use intermediate header (dest options)
  2.       yes    use mobility header (no piggyback)

And just check on receive whether IPSEC was applied or not (reject
packet, report error or something).

---

From: Markku Savela <[email-masked]>
Date: Fri, 15 Mar 2002 22:27:07 +0200

... which prompts me query, why need a new protocol number even. Would
this look too kludgy?

  - non final mobility: use the destination options (as originally
    specified)

  - when IPSEC is desired, send the destination options in separate
    UDP packet, and pick a well known port for it (assign it to
    mobility).