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

From: "Don Provan \(E-mail\)" <[email-masked]>
Date: Mon, 3 Feb 2003 10:06:34 -0800

Alexandre,

I think I understand what you're going for since I've
also felt the need for it. But what I'm thinking of
would be better called "down" rather than "fault".
Not only does "down" better reflect the VRRP state (as
opposed to the interface state), it also reminds us
that nothing is necessarily wrong in that state. For
example, this would be the state of the VRRP machine
if the interface was simply kept down administratively
or hadn't yet come up.

Or am I thinking of some entirely different state?

In any case, I would think the only way out of "fault"
(or "down") would be to init, but the drawing has the
fault exists go directly to master or backup, never to
init. Is the decision between master and backup
different when coming out of fault than it is coming
out of init?

-don

p.s. But didn't we just all decide that there's no
point to IPSEC-AH authentication in VRRP?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Alexandre Cassen
> Sent: Thursday, January 30, 2003 3:10 PM
> To: Mukesh Gupta
> Cc: [email-masked]
> Subject: [VRRP] VRRP IPSEC-AH FSM extension
>
>
> Hi Mukesh,
>
> I am currently writing the draft we discussed in a previous
> mail... In
> the discussion I need to offer an extended VRRP FSM design to
> expose all
> possible AH case. The FSM diagram I propose is the following :
>
>                               +---------------+
>              +----------------|               |----------------+
>              |                |     Fault     |                |
>              |  +------------>|               |<------------+  |
>              |  |             +---------------+             |  |
>              |  |                     ^                     |  |
>              |  |                     |                     |  |
>              |  |             +---------------+             |  |
>              |  |  +--------->|               |<---------+  |  |
>              |  |  |          |  Initialize   |          |  |  |
>              |  |  |  +-------|               |-------+  |  |  |
>              |  |  |  |       +---------------+       |  |  |  |
>              |  |  |  |                               |  |  |  |
>              V  |  |  V                               V  |  |  V
>           +---------------+                       +---------------+
>           |               |---------------------->|               |
>           |    Master     |                       |    Backup     |
>           |               |<----------------------|               |
>           +---------------+                       +---------------+
>
>
> I just add a new STATE : the FAULT state. This state is reflecting an
> interface physical state : shut or no shut, due to hardware failure,
> media link detection failure, ... All layer1 related errors.
> Since VRRP
> is extremly interface state dependent, I really think this
> state must be
> considered. There is two point of view, integrating this
> state directly
> into Master and Backup state but creating a new dedicated
> state  can be
> , IMHO, better for devel point of view, since FSM implementation is
> simplest. Especially for IPSEC-AH extension. What is your opinion ?
>
> Best regards,
> Alexandre
>
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/vrrp

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

---

From: Alexandre Cassen <[email-masked]>
Date: Mon, 03 Feb 2003 21:42:15 +0100

Hi Don,

> if the interface was simply kept down administratively

hmm, :) phylosophic point here. If interface is admin shuted down then 
"DOWN" word is better, if link media failure or hard blackout "FAULT" 
can makes sens. But if we purely consider CISCO VTY vocabulary, then 
DOWN is prefered... To your conveniance... not a problem for me, just 
wanted to point out that this FSM state is needed since VRRP, like HSRP 
is closed to layer1, and interface state (admin or not) must introduce 
FSM state transition in order to handle all consistent case.

> different when coming out of fault than it is coming

After re-reading my code indepth the FSM implemented is :

                               +---------------+
                               |               |
                 +------------>|     Fault     |<------------+
                 |             |               |             |
                 |             +---------------+             |
                 |                    |  ^                   |
                 |                    v  |                   |
                 |             +---------------+             |
                 |  +--------->|               |<---------+  |
                 |  |          |  Initialize   |          |  |
                 |  |  +-------|               |-------+  |  |
                 |  |  |       +---------------+       |  |  |
                 |  |  |                               |  |  |
                 |  |  V                               V  |  |
           +---------------+                       +---------------+
           |               |---------------------->|               |
           |    Master     |                       |    Backup     |
           |               |<----------------------|               |
           +---------------+                       +---------------+

Some considerations :

1. All stable state must be able to transit to FAULT state
2. FAULT state can only transit to INIT state to provoque a new VRRP 
protocol convergence.

That way we design a n(n-1) FSM and optimize the 2 FAULT state 
transition to INIT => n(n-1)-2 => 10 transitions to handle.

> point to IPSEC-AH authentication in VRRP?

We had a thread on this I remember but I don't share this position :). 
IMHO, IPSEC-AH with provisions for MCAST env can make VRRP more secure 
especially for anti-replay attack and ICV benefit... We can debate if 
you want.

Best regards,
Alexandre

---

From: Mark Baugher <[email-masked]>
Date: Mon, 03 Feb 2003 14:33:20 -0800

hello,
   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?

thanks, Mark

>especially for anti-replay attack and ICV benefit... We can debate if you want.
>
>Best regards,
>Alexandre
>

---

From: "Don Provan" <[email-masked]>
Date: Mon, 3 Feb 2003 09:33:05 -0800

Alexandre,

-don