Subject: [mobile-ip] MIPv6 Security Issues (Update on issues Closed and Open)

From: [email-masked]
Date: Tue, 12 Mar 2002 18:16:11 -0600

Hello,

This is an update on the status of issues that were still open as per
the staus update email sent on Feb 22nd:

There were three open issues:

1. Piggybacking						[Closed]
2. Home Address destination option processing		[Closed]
   (Discussed on the list as Unverified HAO Processing)
3. The bit mechanism to turn on/off RR			[Open]

Issues 1 and 2 are now closed. Resolutions on these issues are as
follows:

1. Piggybacking
===============
As per the DT recommendations [Sent Feb 25th] on  which are:

R1. A Separate protocol should be used for the BR message, all RR
    messages, BU message and BA message.  This will allow - but not
    mandate - the use of current IPsec selectors in protecting BUs to
    the CN and HA, and RR messages via the HA. The value of next
    protocol = none must be supported by all MIPv6 compliant nodes in
    these messages.

R2. Reserve some space for preference bits in the RR messages 1a and
     1b, to allow the CN and the MN to describe their
     preferences. Only the space is reserved, but no meaning is
     assigned to the bits. 

R3. The above two recommendations should be placed in the MIPv6
     RFC. This would allow us to quickly proceed to RFC 
     status by bypassing controversial content, have as simple
     RFC and implementations as possible, but still allow
     functionality like piggybacking to be specified without
     interoperability concerns, and used by all nodes who
     support it.

R4. Separate RFCs would define the use of these bits and guidelines
    for supporting piggybacking in the presence of IPsec.

2. Unverified HAO Processing
============================
As per the conclusions/recommendation [Sent March 8th]:

The base Mobile IPv6 specification will take the following approach:
- CNs must not process packets with Unverified HAO 
- A CN must send an error response to a MN sending packets with
  unverified HAO , indicating its inability to process such packets by
  sending an error message specified in the base draft.
   * This error mechanism should be extensible so that different types
     of error notification can be added e.g. when unvHAO support is
     specified.  

- With future extensions and specification, MNs may optimistically
  send packets with unverified HAO to a CN, but on receiving an error
  response, MNs  must resort to bidirectional tunnelling to send
  packets to the CN. 

-Basavaraj