headers
Don Provan (E-mail | 3 Feb 2003 19:06
Favicon

RE: VRRP IPSEC-AH FSM extension

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: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> Alexandre Cassen
> Sent: Thursday, January 30, 2003 3:10 PM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandre Cassen | 3 Feb 2003 21:42
Picon

Re: VRRP IPSEC-AH FSM extension

Hi Don,

> 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.

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.

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

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

                               +---------------+
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Baugher | 3 Feb 2003 23:33
Picon
Favicon

Re: VRRP IPSEC-AH FSM extension

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

>>p.s. But didn't we just all decide that there's no
>>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
>
>_______________________________________________
>vrrp mailing list
>vrrp <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Provan | 3 Feb 2003 18:33

RE: VRRP IPSEC-AH FSM extension

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: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> Alexandre Cassen
> Sent: Thursday, January 30, 2003 3:10 PM
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mukesh Gupta | 21 Feb 2003 04:31
Picon

Security Issues with VRRP. (Final Proposal)

Folks,

I wanted to finalize what to do about the security issues in VRRP. On the basis of the
discussions we had, this is what my conclusion is:

- Clear text authentication doesn't provide any security to VRRP and instead of
helping in cases of mis-configuration, it makes the situation worse by having 2
masters.

- IPsec AH security might help a little bit in some cases (as discussed on the list)
but the current draft doesn't provide enough details to implement it. We have been
looking for volunteers to complete this for long time and the draft has not been able
to make any process because there is not enough interest in the WG. It is questionable
that the work needed in order to complete this, is worth the security it will provide.

This is what my final proposal is in order to move forward in a timely manner:

===
We remove the security completely from VRRP (both v2 and v3) and write a good security
consideration section about why it is not needed. Then we can independently work on a
separate draft (providing there is enough interest) about providing IPsec AH security
to VRRP. IPsec is supposed to provide transparent security to the applications like
VRRP anyway. So ideally, it shouldn't affect VRRP specs.
===

I wanted to take the final comments from the WG members. Please raise your voice, if
you have problems with this proposal. I will wait for a week (till 27th Feb) and if I
don't hear enough resistence, we will move ahead with this proposal.

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mukesh Gupta | 21 Feb 2003 04:42
Picon

The usefulness of Priority 0 VRRP packet.

Folks,

During the discussions on VRRP security, someone had raised a case where
IPsec AH security would have helped a bit. The case was the
vulnerability of DOS attack using Priority 0 (current master stopped
participating) VRRP packet.

As we are planning to remove the security completely from VRRP, I wanted
to get an idea about the usefulness of this priority 0 packet defined in
VRRP spec. If it is not more useful than the security risks it exposed
VRRP to, we could consider removing it from the spec.

Please express your opinion about this packet.

Regards,
Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
Jeffrey Haas | 21 Feb 2003 15:50

Re: The usefulness of Priority 0 VRRP packet.

Mukesh,

I was asked to review VRRP by our company.  I have no actual implementation
or operational experience, so please take my comments with a grain of
salt.

As specified, the priority 0 (explicit withdrawal) is useful under
some graceful restart type situations.  It should be kept.

IMO, the only way to truly "fix" VRRP as specified is to replace ARP
with something that is secure that includes a VRRP-like mechanism.

While that might be nice, I find it highly unlikely to ever happen.

On Thu, Feb 20, 2003 at 07:42:50PM -0800, Mukesh Gupta wrote:
> During the discussions on VRRP security, someone had raised a case where
> IPsec AH security would have helped a bit. The case was the
> vulnerability of DOS attack using Priority 0 (current master stopped
> participating) VRRP packet.
> 
> As we are planning to remove the security completely from VRRP, I wanted
> to get an idea about the usefulness of this priority 0 packet defined in
> VRRP spec. If it is not more useful than the security risks it exposed
> VRRP to, we could consider removing it from the spec.
> 
> Please express your opinion about this packet.
> 
> Regards,
> Mukesh
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mukesh Gupta | 25 Feb 2003 21:08
Picon

Important Meeting Dates..

Important meeting dates for IETF 56th..

February 25, Tuesday - Working Group and BOF scheduling closes at 17:00
ET
March 3, Monday - Internet Draft final submission cut-off at 09:00 ET
March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET
March 12, Wednesday - Registration cancellation cut-off at 17:00 ET
March 13, Thursday - Working Group agendas due date at 12:00 ET
March 16-21 - 56th IETF Meeting in San Francisco, CA
April 14, Monday - Proceedings submission cutoff date by 17:00 ET

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mukesh Gupta | 25 Feb 2003 21:12
Picon

VRRP meeting schedule at IETF 56th.

VRRP WG is scheduled to meet at IETF 56th. Here is the schedule from the
draft agenda.

====
THURSDAY, March 20, 2003

1530-1730 Afternoon Sessions II
INT      eap         Extensible Authentication Protocol WG
OPS     ipfix        IP Flow Information Export WG
RTG     vrrp        Virtual Router Redundancy Protocol WG
SEC     saag        Open Security Area Directorate
TSV     mmusic    Multiparty Multimedia Session Control WG
TSV     pads &
            plpmtud    Path-Decoupled Signaling BOF & Packetization
Layer Path MTU Discovery BOF
====

regards
Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mukesh Gupta | 25 Feb 2003 21:13
Picon

Agenda items for the WG meeting.

Hi All,

I am working on the agenda for the WG meeting at IETF 56th in San
Francisco. Please send me any agenda items you might have.

regards
Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |

Gmane