Subject: Re: [VRRP] VRRP IPSEC-AH FSM extension

From: "Alexandre Cassen" <[email-masked]>
Date: Wed, 05 Feb 2003 13:35:07 +0100 (MET)

Hi,

>  I merely lurk on this list, pardon me, but I recall that a consensus to 
> support Radia Perlman's approach on authentication services for VPPN.  As I 
> recall, the consensus is that it is an unneeded complication of 
> questionable security value.
>
>    Did I get that right?

In my humble opinion, the AH type can be good. I agree this introduce some
complication in the VRRP FSM, but we can make an adaptation of IPSEC-AH
for our needs. Reading the IETF MSEC WG publications, I agree the IKE and
ISAKMP MCAST adaptation is a little too much for our simple needs. If I
can sum our need for AH :

1. Provide strong anti-replay design
2. Provide Integrity Check Value for VRRP adverts

The IPSEC-AH SPI is not really consistent since we are in a "many to many"
dialog. So the IPSEC SA MCAST adaptation introduce to much complications.
In a first thought, reading some draft on MCAST, I adopted the :

   /* The SPI value is filled with the ip header source address.
      SPI uniquely identify the Security Association (SA). This value
      is chosen by the recipient itself when setting up the SA. In a
      multicast environment, this becomes unfeasible.

      If left to the sender, the choice of the SPI value should be done
      so by the sender that it cannot possibly conflict with SPI values
      chosen by other entities sending IPSEC traffic to any of the receivers.
      To overpass this problem, the rule I have chosen to implement here is
      that the SPI value chosen by the sender is based on unique information
      such as its IP address.
      -- INTERNET draft : <draft-paridaens-xcast-sec-framework-01.txt>
    */

So to sum the only IPSEC interresting mecanism for us is the IPSEC sequence
number. Since this seq_num is part of the Keyed digest this pervent against
anti-replay. This introduce the need for VRRP to deal with seq_num
synchronization into the FSM. FSM much also take care of seq_num cycle.

This can be viewed as an adaptation/degradation of IPSEC-AH for VRRP needs.
So we can ask if this can be called IPSEC-AH :) since our need if only
anti-replay and ICV this is not fully IPSEC. So here we can consider 2
alternative.

1. We continue using this IPSEC-AH denomination and place all this
   security part into the so called IPSEC-AH header.
2. We review a little the VRRP packet format adding 2 new fileds :
   * VRRP Sequence Number Field
   * VRRP Authentication data (HMAC-MD5-96bit for padding simplification)

IMHO, the 1 is better since if we don t use AH auth there is no need
to have those field present into the VRRP packets. Its much clear to
use separate/dedicated header...

Best regards,
Alexandre

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp