Subject: RE: [mobile-ip] Text and proposal for piggybacking

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Fri, 8 Mar 2002 11:36:46 +0100

Hi,

> X.Z Which Mobility Signals to Piggyback
> 
>    An implementation sends piggyback when its negotiation
>    result with the peer allows and if it makes sense for
>    the mobility signal in question.
> 
>    Mobility signals include BR/BU/BAck and the RR messages. 
>    Piggybacking of BR/BU/BAck messages between the MN and HA is very
>    rare. It can be done only when the payload belongs to a session
>    between the MN and HA. For piggybacking between MN and CN,
>    Table 2 describes when a mobility signal can be piggybacked.
> 
>           Table 2: Mobility Signals and Piggybacking (adapted from 
>                    Design Team's writeup with small changes)
> 
>      Message                     Sndr       Rcvr          Pig
> 
>      Binding Request              CN         MN           Yes
>      Binding Update               MN         CN           Yes
>      Binding Acknowledgment       CN         MN           Yes
>      RR 1a                        MN         CN           Yes*
>      RR 1b                        MN         CN           Yes*
>      RR 2a                        CN         MN           Yes? 
>      RR 2b                        CN         MN            No 
> 
>      A (*) indicates that piggybacking would be sometimes possible
>      (details in the DT writeup).
> 
>      A (?) - cant it be piggybacked?? not sure. didnt quite understand
>      what the DT was trying to say about a 'rogue HA'.
> 

I would like to stress that if, as recommended by the DT, the HA-MN tunnel
should be encrypted for the RR messages and only for those, then the IPSEC selector
must be able to detect these messages and hence 
RR 1a and RR 2a becomes definitive NO piggybacking (i.e. final protocol elements)
- although no authentication is needed for the RR messages them selves.

BR, Karen