From mailnull@www1.ietf.org Mon Feb 3 13:08:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15337 for ; Mon, 3 Feb 2003 13:08:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13ID6q10753 for vrrp-archive@odin.ietf.org; Mon, 3 Feb 2003 13:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13ID6J10750 for ; Mon, 3 Feb 2003 13:13:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15328 for ; Mon, 3 Feb 2003 13:07:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13I8cJ10582; Mon, 3 Feb 2003 13:08:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13I7wJ10546 for ; Mon, 3 Feb 2003 13:07:58 -0500 Received: from exmail.bivio.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15211 for ; Mon, 3 Feb 2003 13:02:22 -0500 (EST) Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Feb 2003 10:06:38 -0800 From: "Don Provan \(E-mail\)" To: "'Alexandre Cassen'" Cc: Subject: RE: [VRRP] VRRP IPSEC-AH FSM extension Date: Mon, 3 Feb 2003 10:06:34 -0800 Message-ID: <000101c2cbae$ff3e82b0$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3E39B0C8.9060207@wanadoo.fr> X-OriginalArrivalTime: 03 Feb 2003 18:06:38.0863 (UTC) FILETIME=[FF59F9F0:01C2CBAE] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , 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@ietf.org [mailto:vrrp-admin@ietf.org]On Behalf Of > Alexandre Cassen > Sent: Thursday, January 30, 2003 3:10 PM > To: Mukesh Gupta > Cc: vrrp@ietf.org > 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 > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Mon Feb 3 15:42:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20997 for ; Mon, 3 Feb 2003 15:42:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13KlEx24304 for vrrp-archive@odin.ietf.org; Mon, 3 Feb 2003 15:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KlEJ24301 for ; Mon, 3 Feb 2003 15:47:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20976 for ; Mon, 3 Feb 2003 15:41:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KkJJ24274; Mon, 3 Feb 2003 15:46:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KjEJ24173 for ; Mon, 3 Feb 2003 15:45:14 -0500 Received: from mel-rto4.wanadoo.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20876 for ; Mon, 3 Feb 2003 15:39:35 -0500 (EST) Received: from mel-rta6.wanadoo.fr (193.252.19.26) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD017D46C4; Mon, 3 Feb 2003 21:43:04 +0100 Received: from wanadoo.fr (80.14.19.48) by mel-rta6.wanadoo.fr (6.7.015) id 3E26CE2100AAA6BE; Mon, 3 Feb 2003 21:43:04 +0100 Message-ID: <3E3ED427.2000407@wanadoo.fr> Date: Mon, 03 Feb 2003 21:42:15 +0100 From: Alexandre Cassen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Provan CC: vrrp@ietf.org Subject: Re: [VRRP] VRRP IPSEC-AH FSM extension References: <00ae01c2cbaa$4fd8ead0$8918a8c0@corp.networkrobots.com> In-Reply-To: <00ae01c2cbaa$4fd8ead0$8918a8c0@corp.networkrobots.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 : +---------------+ | | +------------>| 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. > 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@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Mon Feb 3 17:32:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23990 for ; Mon, 3 Feb 2003 17:32:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13MbHL31698 for vrrp-archive@odin.ietf.org; Mon, 3 Feb 2003 17:37:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MbGJ31687 for ; Mon, 3 Feb 2003 17:37:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23951 for ; Mon, 3 Feb 2003 17:31:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MaHJ31198; Mon, 3 Feb 2003 17:36:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MZQJ31140 for ; Mon, 3 Feb 2003 17:35:26 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23906 for ; Mon, 3 Feb 2003 17:29:44 -0500 (EST) Received: from cscoamera13263.cisco.com (sjc-vpn2-1364.cisco.com [10.21.117.84]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h13MXFB7021445 for ; Mon, 3 Feb 2003 14:33:15 -0800 (PST) Message-Id: <5.1.1.5.2.20030203142950.0523f170@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 03 Feb 2003 14:33:20 -0800 To: vrrp@ietf.org From: Mark Baugher Subject: Re: [VRRP] VRRP IPSEC-AH FSM extension In-Reply-To: <3E3ED427.2000407@wanadoo.fr> References: <00ae01c2cbaa$4fd8ead0$8918a8c0@corp.networkrobots.com> <00ae01c2cbaa$4fd8ead0$8918a8c0@corp.networkrobots.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , 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@ietf.org >https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Wed Feb 5 07:33:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22501 for ; Wed, 5 Feb 2003 07:33:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15Cdqd21597 for vrrp-archive@odin.ietf.org; Wed, 5 Feb 2003 07:39:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CdqJ21594 for ; Wed, 5 Feb 2003 07:39:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22461 for ; Wed, 5 Feb 2003 07:33:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CcWJ21554; Wed, 5 Feb 2003 07:38:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CbwJ21530 for ; Wed, 5 Feb 2003 07:37:58 -0500 Received: from mel-rto4.wanadoo.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22357 for ; Wed, 5 Feb 2003 07:31:29 -0500 (EST) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD018DFBB7 for vrrp@ietf.org; Wed, 5 Feb 2003 13:35:08 +0100 Received: from mail-web2 (193.252.19.159) by mel-rta7.wanadoo.fr (6.7.015) id 3E26CE5400C4D34A for vrrp@ietf.org; Wed, 5 Feb 2003 13:35:08 +0100 Message-ID: <3E26CE5400C4D34A@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Received: from '' by www.wanadoo.fr with HTTP; Date: Wed, 05 Feb 2003 13:35:07 +0100 (MET) From: "Alexandre Cassen" To: Subject: Re: [VRRP] VRRP IPSEC-AH FSM extension MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15CbwJ21531 Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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 : */ 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 vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Sun Feb 16 22:23:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03307 for ; Sun, 16 Feb 2003 22:23:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H3SOv13651 for vrrp-archive@odin.ietf.org; Sun, 16 Feb 2003 22:28:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H3SNp13648 for ; Sun, 16 Feb 2003 22:28:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03304 for ; Sun, 16 Feb 2003 22:22:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H3Igp13395; Sun, 16 Feb 2003 22:18:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HYQJ07137 for ; Mon, 3 Feb 2003 12:34:26 -0500 Received: from exmail.bivio.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14147 for ; Mon, 3 Feb 2003 12:28:51 -0500 (EST) Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Feb 2003 09:33:06 -0800 From: "Don Provan" To: "'Alexandre Cassen'" Cc: Subject: RE: [VRRP] VRRP IPSEC-AH FSM extension Date: Mon, 3 Feb 2003 09:33:05 -0800 Message-ID: <00ae01c2cbaa$4fd8ead0$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3E39B0C8.9060207@wanadoo.fr> X-OriginalArrivalTime: 03 Feb 2003 17:33:06.0598 (UTC) FILETIME=[4FF2B460:01C2CBAA] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , 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@ietf.org [mailto:vrrp-admin@ietf.org]On Behalf Of > Alexandre Cassen > Sent: Thursday, January 30, 2003 3:10 PM > To: Mukesh Gupta > Cc: vrrp@ietf.org > 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 > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Thu Feb 20 22:37:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08152 for ; Thu, 20 Feb 2003 22:37:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L3iHY08108 for vrrp-archive@odin.ietf.org; Thu, 20 Feb 2003 22:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L3iGp08105 for ; Thu, 20 Feb 2003 22:44:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08140 for ; Thu, 20 Feb 2003 22:36:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L3cep07918; Thu, 20 Feb 2003 22:38:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L3ZBp07082 for ; Thu, 20 Feb 2003 22:35:11 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07745 for ; Thu, 20 Feb 2003 22:27:48 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1L3VjO27233 for ; Thu, 20 Feb 2003 21:31:45 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Feb 2003 21:31:38 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 19:31:37 -0800 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 21:31:37 -0600 Message-ID: <3E559D98.9B0D61B7@nokia.com> Date: Thu, 20 Feb 2003 19:31:36 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vrrp@ietf.org CC: Radia Perlman References: <200302041548.h14Fm3M06087@sydney.East.Sun.COM> <53117909925.20030204165108@psg.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2003 03:31:37.0379 (UTC) FILETIME=[BD76C730:01C2D959] Content-Transfer-Encoding: 7bit Subject: [VRRP] Security Issues with VRRP. (Final Proposal) Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, Mukesh _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Thu Feb 20 22:46:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08469 for ; Thu, 20 Feb 2003 22:46:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L3rPf08471 for vrrp-archive@odin.ietf.org; Thu, 20 Feb 2003 22:53:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L3rPp08468 for ; Thu, 20 Feb 2003 22:53:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08452 for ; Thu, 20 Feb 2003 22:46:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L3n4p08308; Thu, 20 Feb 2003 22:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L3kPp08221 for ; Thu, 20 Feb 2003 22:46:25 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08234 for ; Thu, 20 Feb 2003 22:39:01 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1L3grq11811 for ; Thu, 20 Feb 2003 21:42:54 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Feb 2003 21:42:52 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 21:42:51 -0600 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 21:42:50 -0600 Message-ID: <3E55A03A.EE257BCD@nokia.com> Date: Thu, 20 Feb 2003 19:42:50 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vrrp@ietf.org CC: Radia Perlman Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2003 03:42:50.0919 (UTC) FILETIME=[4EECD370:01C2D95B] Content-Transfer-Encoding: 7bit Subject: [VRRP] The usefulness of Priority 0 VRRP packet. Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Fri Feb 21 09:56:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01907 for ; Fri, 21 Feb 2003 09:56:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LF3KR28203 for vrrp-archive@odin.ietf.org; Fri, 21 Feb 2003 10:03:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LF3Jp28200 for ; Fri, 21 Feb 2003 10:03:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01899 for ; Fri, 21 Feb 2003 09:55:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEvrp27858; Fri, 21 Feb 2003 09:57:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEsKp27745 for ; Fri, 21 Feb 2003 09:54:20 -0500 Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01699 for ; Fri, 21 Feb 2003 09:46:43 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1LEoSp74938; Fri, 21 Feb 2003 09:50:28 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1LEoPC74931; Fri, 21 Feb 2003 09:50:25 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1LEoPM07595; Fri, 21 Feb 2003 09:50:25 -0500 (EST) Date: Fri, 21 Feb 2003 09:50:25 -0500 From: Jeffrey Haas To: Mukesh Gupta Cc: vrrp@ietf.org, Radia Perlman Subject: Re: [VRRP] The usefulness of Priority 0 VRRP packet. Message-ID: <20030221095025.D7506@nexthop.com> References: <3E55A03A.EE257BCD@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E55A03A.EE257BCD@nokia.com>; from mukesh.gupta@nokia.com on Thu, Feb 20, 2003 at 07:42:50PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , 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 -- Jeff Haas NextHop Technologies _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Tue Feb 25 15:14:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13514 for ; Tue, 25 Feb 2003 15:14:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PKO5P27555 for vrrp-archive@odin.ietf.org; Tue, 25 Feb 2003 15:24:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKO4p27552 for ; Tue, 25 Feb 2003 15:24:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13466 for ; Tue, 25 Feb 2003 15:14:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKINp27184; Tue, 25 Feb 2003 15:18:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKDqp27020 for ; Tue, 25 Feb 2003 15:13:52 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13070 for ; Tue, 25 Feb 2003 15:04:11 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1PK87q27266 for ; Tue, 25 Feb 2003 14:08:07 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Feb 2003 14:08:05 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 14:08:04 -0600 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 14:08:04 -0600 Message-ID: <3E5BCD23.81D78954@nokia.com> Date: Tue, 25 Feb 2003 12:08:03 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vrrp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2003 20:08:04.0292 (UTC) FILETIME=[9AE4B840:01C2DD09] Content-Transfer-Encoding: 7bit Subject: [VRRP] Important Meeting Dates.. Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Tue Feb 25 15:16:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13573 for ; Tue, 25 Feb 2003 15:16:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PKPSS27677 for vrrp-archive@odin.ietf.org; Tue, 25 Feb 2003 15:25:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKPSp27674 for ; Tue, 25 Feb 2003 15:25:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13554 for ; Tue, 25 Feb 2003 15:15:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKLGp27359; Tue, 25 Feb 2003 15:21:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKI3p27172 for ; Tue, 25 Feb 2003 15:18:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13165 for ; Tue, 25 Feb 2003 15:08:22 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1PKFNm10954 for ; Tue, 25 Feb 2003 22:15:23 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Feb 2003 22:12:16 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 22:12:16 +0200 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 12:12:13 -0800 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 14:12:12 -0600 Message-ID: <3E5BCE1C.1ABA28C1@nokia.com> Date: Tue, 25 Feb 2003 12:12:12 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vrrp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2003 20:12:13.0029 (UTC) FILETIME=[2F26F950:01C2DD0A] Content-Transfer-Encoding: 7bit Subject: [VRRP] VRRP meeting schedule at IETF 56th. Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Tue Feb 25 15:19:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13657 for ; Tue, 25 Feb 2003 15:19:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PKShp27848 for vrrp-archive@odin.ietf.org; Tue, 25 Feb 2003 15:28:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKShp27845 for ; Tue, 25 Feb 2003 15:28:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13649 for ; Tue, 25 Feb 2003 15:19:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKNHp27431; Tue, 25 Feb 2003 15:23:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKIwp27200 for ; Tue, 25 Feb 2003 15:18:58 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13208 for ; Tue, 25 Feb 2003 15:09:17 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1PKBs226079 for ; Tue, 25 Feb 2003 22:11:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Feb 2003 22:13:07 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 22:13:06 +0200 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 14:13:02 -0600 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 14:13:02 -0600 Message-ID: <3E5BCE4E.D01DA5A0@nokia.com> Date: Tue, 25 Feb 2003 12:13:02 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vrrp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2003 20:13:02.0608 (UTC) FILETIME=[4CB42100:01C2DD0A] Content-Transfer-Encoding: 7bit Subject: [VRRP] Agenda items for the WG meeting. Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Tue Feb 25 17:09:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19759 for ; Tue, 25 Feb 2003 17:09:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PMIx403878 for vrrp-archive@odin.ietf.org; Tue, 25 Feb 2003 17:18:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMIxp03875 for ; Tue, 25 Feb 2003 17:18:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19745 for ; Tue, 25 Feb 2003 17:09:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMDMp03588; Tue, 25 Feb 2003 17:13:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMAUp03471 for ; Tue, 25 Feb 2003 17:10:30 -0500 Received: from mel-rto2.wanadoo.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19480 for ; Tue, 25 Feb 2003 17:00:47 -0500 (EST) Received: from mel-rta6.wanadoo.fr (193.252.19.26) by mel-rto2.wanadoo.fr (6.7.015) id 3E0C33700267E01B; Tue, 25 Feb 2003 23:04:42 +0100 Received: from wanadoo.fr (80.14.19.97) by mel-rta6.wanadoo.fr (6.7.015) id 3E26CE21017067D3; Tue, 25 Feb 2003 23:04:42 +0100 Message-ID: <3E5BE84A.6060606@wanadoo.fr> Date: Tue, 25 Feb 2003 23:03:54 +0100 From: Alexandre Cassen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vrrp@ietf.org CC: Mukesh Gupta Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [VRRP] VRRP IPSEC-AH specs Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, As previously discussed with Mukesh, I have written down a short draft explaining VRRP IPSEC-AH authentication method specs used in Keepalived VRRP framework. You can find this small paper at : www.keepalived.org Any comments are welcomes. Best regards, Alexandre _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Tue Feb 25 21:07:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25290 for ; Tue, 25 Feb 2003 21:07:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1Q2Gav17644 for vrrp-archive@odin.ietf.org; Tue, 25 Feb 2003 21:16:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q2Gap17641 for ; Tue, 25 Feb 2003 21:16:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25287 for ; Tue, 25 Feb 2003 21:06:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q2BCp17370; Tue, 25 Feb 2003 21:11:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q28wp17260 for ; Tue, 25 Feb 2003 21:08:58 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25091 for ; Tue, 25 Feb 2003 20:59:11 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1Q26Cm23078 for ; Wed, 26 Feb 2003 04:06:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Feb 2003 04:03:03 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 04:03:03 +0200 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 18:03:00 -0800 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 20:03:00 -0600 Message-ID: <3E5C2054.6E9DBE4F@nokia.com> Date: Tue, 25 Feb 2003 18:03:00 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ext Alexandre Cassen CC: vrrp@ietf.org References: <3E5BE84A.6060606@wanadoo.fr> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 02:03:00.0431 (UTC) FILETIME=[3061A5F0:01C2DD3B] Content-Transfer-Encoding: 7bit Subject: [VRRP] Re: VRRP IPSEC-AH specs Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The complete location is http://www.keepalived.org/draft-ietf-vrrp-ipsecah-spec-00.txt As we have passed the deadline for submitting 00 version of the draft before IETF 56th, it will be submitted to internet-drafts after IETF 56th. Please provide your valuable feedback/comments to the mailing list. regards Mukesh ext Alexandre Cassen wrote: > Hi, > > As previously discussed with Mukesh, I have written down a short draft > explaining VRRP IPSEC-AH authentication method specs used in Keepalived > VRRP framework. > > You can find this small paper at : www.keepalived.org > > Any comments are welcomes. > > Best regards, > Alexandre _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Wed Feb 26 05:38:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00280 for ; Wed, 26 Feb 2003 05:38:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAlvt29504 for vrrp-archive@odin.ietf.org; Wed, 26 Feb 2003 05:47:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAlvp29501 for ; Wed, 26 Feb 2003 05:47:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00276 for ; Wed, 26 Feb 2003 05:37:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAgTp29258; Wed, 26 Feb 2003 05:42:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAbWp28964 for ; Wed, 26 Feb 2003 05:37:32 -0500 Received: from theta.ensoft.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00070 for ; Wed, 26 Feb 2003 05:27:34 -0500 (EST) Received: from gamma.ensoft.co.uk ([172.19.1.5]) by theta.ensoft.co.uk with esmtp (Exim 3.22 #1) id 18nyqO-0000ZS-00; Wed, 26 Feb 2003 10:31:20 +0000 Received: by gamma.ensoft.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 10:31:20 -0000 Message-ID: <7161E47FDFEFD51181BE00B0D0FAD655345D50@gamma.ensoft.co.uk> From: Thomas Dalton To: "'Mukesh Gupta'" , ext Alexandre Cassen Cc: vrrp@ietf.org Subject: RE: [VRRP] Re: VRRP IPSEC-AH specs Date: Wed, 26 Feb 2003 10:31:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Hi, Just one question: Why do you need a "Fault" state? - If a Shutdown event is received, then: o Cancel the Master_Down_Timer o Transition to the {Initialize} state endif Can the various faults not be considered to be "Shutdown events" and hence the "Initialize" state will account for this? Indeed, if you merged the ammended FSM diagram such that Fault and Initialize were one state, you'd have exactly the same as that in RFC2338. Cheers, Tom > -----Original Message----- > From: Mukesh Gupta [mailto:mukesh.gupta@nokia.com] > Sent: Wednesday, February 26, 2003 2:03 AM > To: ext Alexandre Cassen > Cc: vrrp@ietf.org > Subject: [VRRP] Re: VRRP IPSEC-AH specs > > > The complete location is > http://www.keepalived.org/draft-ietf-vrrp-ipsecah-spec-00.txt > > As we have passed the deadline for submitting 00 version of the draft > before IETF 56th, it will be submitted to internet-drafts > after IETF 56th. > > Please provide your valuable feedback/comments to the mailing list. > > regards > Mukesh > > ext Alexandre Cassen wrote: > > > Hi, > > > > As previously discussed with Mukesh, I have written down a > short draft > > explaining VRRP IPSEC-AH authentication method specs used > in Keepalived > > VRRP framework. > > > > You can find this small paper at : www.keepalived.org > > > > Any comments are welcomes. > > > > Best regards, > > Alexandre > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Wed Feb 26 06:37:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01527 for ; Wed, 26 Feb 2003 06:37:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QBkaV01032 for vrrp-archive@odin.ietf.org; Wed, 26 Feb 2003 06:46:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBkZp01029 for ; Wed, 26 Feb 2003 06:46:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01455 for ; Wed, 26 Feb 2003 06:36:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBfBp00842; Wed, 26 Feb 2003 06:41:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBckp00692 for ; Wed, 26 Feb 2003 06:38:47 -0500 Received: from mel-rto4.wanadoo.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01306 for ; Wed, 26 Feb 2003 06:28:46 -0500 (EST) Received: from mel-rta10.wanadoo.fr (193.252.19.193) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD026B7152; Wed, 26 Feb 2003 12:32:40 +0100 Received: from mail-web6 (193.252.19.156) by mel-rta10.wanadoo.fr (6.7.015) id 3E26DAA6017180D3; Wed, 26 Feb 2003 12:32:40 +0100 Message-ID: <3E26DAA6017180D3@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) Received: from '' by www.wanadoo.fr with HTTP; Date: Wed, 26 Feb 2003 12:32:40 +0100 (MET) From: "Alexandre Cassen" To: Cc: , References: <7161E47FDFEFD51181BE00B0D0FAD655345D50@gamma.ensoft.co.uk> Subject: RE: [VRRP] Re: VRRP IPSEC-AH specs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QBcqp00700 Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Tom, > Just one question: > > Why do you need a "Fault" state? > > > - If a Shutdown event is received, then: > > o Cancel the Master_Down_Timer > o Transition to the {Initialize} state > > endif > > > Can the various faults not be considered to be "Shutdown events" and hence > the "Initialize" state will account for this? > > Indeed, if you merged the ammended FSM diagram such that Fault and > Initialize were one state, you'd have exactly the same as that in RFC2338. I agree, this is for explicit reasons. Because Init_state in charge of link media failure detection is not really explicit. Creating a new dedicated state for this event introduce timer independance in the FSM implementation, you can fine the timer optimization. Anyway in the Init_state there is a really world need for a 'pending' state processing. Either we kept this in Init_state with the 'pending' extension, or we create a dedicate state. IMHO, creating a new state is better since its reflect a real event. Considering FSM design, this new state doesn't add state handling duplications since this push the FSM into a n(n-1)-2 state transition matrix. Best regards, Alexandre _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Wed Feb 26 13:08:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18480 for ; Wed, 26 Feb 2003 13:08:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QIICV31484 for vrrp-archive@odin.ietf.org; Wed, 26 Feb 2003 13:18:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QIICp31481 for ; Wed, 26 Feb 2003 13:18:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18470 for ; Wed, 26 Feb 2003 13:08:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QICcp31154; Wed, 26 Feb 2003 13:12:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI97p31012 for ; Wed, 26 Feb 2003 13:09:07 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18206 for ; Wed, 26 Feb 2003 12:58:59 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1QI1c226498 for ; Wed, 26 Feb 2003 20:01:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Feb 2003 20:02:53 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 20:02:53 +0200 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 10:02:48 -0800 Received: from nokia.com ([172.19.66.170]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 12:02:48 -0600 Message-ID: <3E5D0148.D3DED0AB@nokia.com> Date: Wed, 26 Feb 2003 10:02:48 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ext Alexandre Cassen CC: thomas.dalton@ensoft.co.uk, vrrp@ietf.org Subject: Re: [VRRP] Re: VRRP IPSEC-AH specs References: <7161E47FDFEFD51181BE00B0D0FAD655345D50@gamma.ensoft.co.uk> <3E26DAA6017180D3@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 18:02:48.0496 (UTC) FILETIME=[458B0300:01C2DDC1] Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Speaking as a WG member] One of the reasons to go with VRRP in IETF against Cisco's HSRP was that VRRP had less number of states, events and message types. (http://ietf.org/proceedings/97aug/slides/rtg/vrrp-status/P010.html) It would be a good idea not to add a new state (unless it is really needed) in order to maintain the benefits of VRRP. regards Mukesh ext Alexandre Cassen wrote: > Hi Tom, > > > Just one question: > > > > Why do you need a "Fault" state? > > > > > > - If a Shutdown event is received, then: > > > > o Cancel the Master_Down_Timer > > o Transition to the {Initialize} state > > > > endif > > > > > > Can the various faults not be considered to be "Shutdown events" and hence > > the "Initialize" state will account for this? > > > > Indeed, if you merged the ammended FSM diagram such that Fault and > > Initialize were one state, you'd have exactly the same as that in RFC2338. > > I agree, this is for explicit reasons. Because Init_state in charge of > link media failure detection is not really explicit. Creating a new > dedicated state for this event introduce timer independance in the > FSM implementation, you can fine the timer optimization. Anyway > in the Init_state there is a really world need for a 'pending' state > processing. Either we kept this in Init_state with the 'pending' > extension, or we create a dedicate state. IMHO, creating a new > state is better since its reflect a real event. Considering FSM > design, this new state doesn't add state handling duplications > since this push the FSM into a n(n-1)-2 state transition matrix. > > Best regards, > Alexandre _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From mailnull@www1.ietf.org Wed Feb 26 16:43:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27326 for ; Wed, 26 Feb 2003 16:43:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QLrLV13894 for vrrp-archive@odin.ietf.org; Wed, 26 Feb 2003 16:53:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLrLp13891 for ; Wed, 26 Feb 2003 16:53:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27276 for ; Wed, 26 Feb 2003 16:42:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLlLp13646; Wed, 26 Feb 2003 16:47:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLiDp13536 for ; Wed, 26 Feb 2003 16:44:13 -0500 Received: from mel-rto3.wanadoo.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26821 for ; Wed, 26 Feb 2003 16:34:01 -0500 (EST) Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto3.wanadoo.fr (6.7.015) id 3E0C33B502725545; Wed, 26 Feb 2003 22:37:55 +0100 Received: from wanadoo.fr (80.15.90.30) by mel-rta8.wanadoo.fr (6.7.015) id 3E26DA7001739825; Wed, 26 Feb 2003 22:37:55 +0100 Message-ID: <3E5D3383.1020305@wanadoo.fr> Date: Wed, 26 Feb 2003 22:37:07 +0100 From: Alexandre Cassen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh Gupta CC: thomas.dalton@ensoft.co.uk, vrrp@ietf.org Subject: Re: [VRRP] Re: VRRP IPSEC-AH specs References: <7161E47FDFEFD51181BE00B0D0FAD655345D50@gamma.ensoft.co.uk> <3E26DAA6017180D3@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) <3E5D0148.D3DED0AB@nokia.com> In-Reply-To: <3E5D0148.D3DED0AB@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, > One of the reasons to go with VRRP in IETF against Cisco's HSRP was that VRRP > had less number of states, events and message types. > (http://ietf.org/proceedings/97aug/slides/rtg/vrrp-status/P010.html) > > It would be a good idea not to add a new state (unless it is really needed) in > order to maintain the benefits of VRRP. hmm, 'Shutdown event' appearing in FSM handling must be specified so :), what are Shutdown events ? and what if this Shutdown event end on a stable state ? I mean if Shutdown event is received (for example interface shut), then Master & Backup state handling will force a transition to Initialize, but when entering Initialize state, interface still shuted, so 'Shutdown event' is a persitent state than must be handled into this Initalize state : with an extension like : (6.4.1) : - If the Priority = 255 (i.e., the router owns the IP address(es) associated with the virtual router) o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router. o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state else if received Shutdown event o transit to internal pending state else if in pending state o keep pending state until pending causes disappear or receiving advert o ... else o Set the Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state endif low-level failure must be handled somewhere, but what is the best place ? a pending state in each FSM state, a pending handling when transiting to Init state on Shutdown receives, a new dedicated FSM state. If for example interface is shuted, then VRRP instance is no longer able of sending/receiving adverts to/from VRRP audience. It is isolated, so if in Master state will keep sending advert and if in Backup state will transit to Master state (since no advert can be received), ... this will finally end on a 'fake' sending Master state, and if using IPSEC-AH for example, why continuing increasing monotonically AH sequence number if audience can't be reached ? in IPSEC this will have 'aging' side effect on sequence numbers depending on the time we are isolated. Best regards, Alexandre _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp