FBU BAD Option

Folks,

In order to protect the FBU and Fback messages, I propose
that we re-use the
BAD option defined in RFC 3775 with an additional SPI field.
The proposed
format is as follows:

    0                   1                   2               
   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
                                  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |     Type      | Option
Length |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |                           SPI                          
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |                                                        
      |
   +                                                        
      +
   |                         Authenticator                  
      |
   +                                                        
      +
   |                                                        
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+


Type: a new type to be assigned

Option Length: Length of the option in octets

SPI: indexes into a particular SA. SPI = 0 is reserved for
SEND-based
Authenticator.

Authenticator: Same as in RFC 3775, with the
"correspondent" set to PAR.

The default MAC calculation is done using HMAC_SHA1 with 96
bits. However,
with Option Length, implementations can use HMAC_SHA256 for
instance.

Algorithm agility, i.e., the ability to use different
algorithms for MAC
calculations should be possible by the individual mechanisms
used to
establish the security association in the first place.

I would like to include this in RFC4068bis. Let me know if
there are any
comments.

Thanks,

-Rajeev



_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop