Re: [BEHAVE] draft-xu-behave-nat-state-sync-00
Jan Melen <jan.melen@nomadiclab.com> Wed, 25 November 2009 19:57 UTC
Return-Path: <jan.melen@nomadiclab.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22953A694C for <behave@core3.amsl.com>; Wed, 25 Nov 2009 11:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.863
X-Spam-Level:
X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VftCKB3BZjpf for <behave@core3.amsl.com>; Wed, 25 Nov 2009 11:57:28 -0800 (PST)
Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 424D33A6820 for <behave@ietf.org>; Wed, 25 Nov 2009 11:57:28 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4E89B1EF1EB; Wed, 25 Nov 2009 21:57:22 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt6cheTI2Z0u; Wed, 25 Nov 2009 21:57:21 +0200 (EET)
Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 9FED31EF12E; Wed, 25 Nov 2009 21:57:20 +0200 (EET)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"; delsp="yes"
From: Jan Melen <jan.melen@nomadiclab.com>
In-Reply-To: <993A3A4FF0FC43A5ACC2846F61546B47@china.huawei.com>
Date: Wed, 25 Nov 2009 21:57:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <443D35DD-DCA2-42B8-8498-7D5CA608B595@nomadiclab.com>
References: <4AFCBC87.20009@gmail.com> <21422_1258094445_4AFCFF6D_21422_40641_1_94C682931C08B048B7A8645303FDC9F307914E625D@PUEXCB1B.nanterre.francetelecom.fr> <42867872-BDDE-42BA-ABF9-4953CEC92B9C@nomadiclab.com> <993A3A4FF0FC43A5ACC2846F61546B47@china.huawei.com>
To: Dean Cheng <Chengd@huawei.com>
X-Mailer: Apple Mail (2.1076)
Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com
Subject: Re: [BEHAVE] draft-xu-behave-nat-state-sync-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2009 19:57:36 -0000
Hi, Well I'm not aware of any complete documentation but I'll try to capture the main points here. First of all it is a binary protocol and in BSD system you can view the state changes by invoking tcpdump for device pfsync. Each packet retrieved on this interface has a header associated with it of length PFSYNC_HDRLEN. The header indicates the version of the protocol, address family, action taken on the following states, and the number of state table entries attached in this packet. This structure is defined in <net/if_pfsync.h> as: struct pfsync_header { u_int8_t version; u_int8_t af; u_int8_t action; #define PFSYNC_ACT_CLR 0 /* clear all states */ #define PFSYNC_ACT_INS 1 /* insert state */ #define PFSYNC_ACT_UPD 2 /* update state */ #define PFSYNC_ACT_DEL 3 /* delete state */ #define PFSYNC_ACT_UPD_C 4 /* "compressed" state update */ #define PFSYNC_ACT_DEL_C 5 /* "compressed" state delete */ #define PFSYNC_ACT_INS_F 6 /* insert fragment */ #define PFSYNC_ACT_DEL_F 7 /* delete fragments */ #define PFSYNC_ACT_UREQ 8 /* request "uncompressed" state */ #define PFSYNC_ACT_BUS 9 /* Bulk Update Status */ #define PFSYNC_ACT_TDB_UPD 10 /* TDB replay counter update */ #define PFSYNC_ACT_MAX 11 u_int8_t count; u_int8_t pf_chksum[PF_MD5_DIGEST_LENGTH]; }; And the state table entries are: struct pfsync_tdb { u_int32_t spi; union sockaddr_union dst; u_int32_t rpl; u_int64_t cur_bytes; u_int8_t sproto; u_int8_t updates; u_int8_t pad[2]; }; struct pfsync_state_upd { u_int32_t id[2]; struct pfsync_state_peer src; struct pfsync_state_peer dst; u_int32_t creatorid; u_int32_t expire; u_int8_t timeout; u_int8_t updates; u_int8_t pad[6]; }; struct pfsync_state_del { u_int32_t id[2]; u_int32_t creatorid; struct { u_int8_t state; } src; struct { u_int8_t state; } dst; u_int8_t pad[2]; }; struct pfsync_state_upd_req { u_int32_t id[2]; u_int32_t creatorid; u_int32_t pad; }; struct pfsync_state_clr { char ifname[IFNAMSIZ]; u_int32_t creatorid; u_int32_t pad; }; struct pfsync_state_bus { u_int32_t creatorid; u_int32_t endtime; u_int8_t status; #define PFSYNC_BUS_START 1 #define PFSYNC_BUS_END 2 u_int8_t pad[7]; }; Regards, Jan On Nov 23, 2009, at 9:19 PM, Dean Cheng wrote: > Hi Jan, > > Do you know whether there exists a protocol specification > for pfsync somewhere so we can take a look? > > Thanks > Dean > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf > Of >> Jan Melen >> Sent: Sunday, November 15, 2009 6:38 AM >> To: <mohamed.boucadair@orange-ftgroup.com> >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 >> >> Hi all, >> >> If we are planning to standardize something should we also take a >> look >> at existing open source solutions that are not based on SCSP such as >> OpenBSD pfsync >> http://www.openbsd.org/cgi-bin/man.cgi?query=pfsync&sektion=4 >> which is used pretty widely at least in the BSD community for nat(/ >> fw) state synchronization? >> >> Regards, >> Jan >> >> On Nov 13, 2009, at 8:40 AM, <mohamed.boucadair@orange-ftgroup.com> >> <mohamed.boucadair@orange-ftgroup.com >>> wrote: >> >>> >>> Dear all, >>> >>> I guess that the question should be asked priori to yours: >>> >>> Do we let vendors define their proprietary solutions or does the >>> IETF define a solution based on standardised protocols to achieve >>> reliable state synchronisation? >>> >>> From a service provider perspective, I'd like to see a solution with >>> IETF stamp so as to be included in our RFPs/analysis. Vendors are >>> then free to propose more reliable solutions, if any, compared to >>> the one standardised by IETF. >>> >>> Cheers, >>> Med >>> >>> >>> -----Message d'origine----- >>> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la >>> part de Brian E Carpenter >>> Envoyé : vendredi 13 novembre 2009 02:55 >>> À : behave@ietf.org >>> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00 >>> >>> My question about this draft is whether there is available code and >>> implementation experience with SCSP, which was defined in 1998. >>> >>> If there isn't code and experience, since it is a quite complex >>> design, I would be a bit worried. >>> >>> On the other hand, I believe that something of the complexity of >>> SCSP is absolutely required to provide reliable synchronisation. >>> There is no simple, lightweight way to do this reliably. >>> >>> Brian >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> ********************************* >>> This message and any attachments (the "message") are confidential >>> and intended solely for the addressees. >>> Any unauthorised use or dissemination is prohibited. >>> Messages are susceptible to alteration. >>> France Telecom Group shall not be liable for the message if altered, >>> changed or falsified. >>> If you are not the intended addressee of this message, please cancel >>> it immediately and inform the sender. >>> ******************************** >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >
- [BEHAVE] draft-xu-behave-nat-state-sync-00 Brian E Carpenter
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 xuxiaohu 41208
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 marcelo bagnulo braun
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dean Cheng
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 marcelo bagnulo braun
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dean Cheng
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Brian E Carpenter
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 mohamed.boucadair
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Jan Melen
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Xu Xiaohu
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dean Cheng
- [BEHAVE] proprietary implementation v.s standardi… Xu Xiaohu
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Jan Melen
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dave Thaler
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… marcelo bagnulo braun
- Re: [BEHAVE] proprietary implementation v.s stand… Joel M. Halpern
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… mohamed.boucadair
- Re: [BEHAVE] proprietary implementation v.s stand… marcelo bagnulo braun
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… mohamed.boucadair
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Joel M. Halpern
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dean Cheng
- Re: [BEHAVE] proprietary implementation v.s stand… Christian Huitema
- Re: [BEHAVE] proprietary implementation v.s stand… mohamed.boucadair
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… mohamed.boucadair
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Dave Thaler
- Re: [BEHAVE] proprietary implementation v.s stand… Andrew Sullivan
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Andrew Sullivan
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… Joel M. Halpern
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… Xu Xiaohu
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… Cameron Byrne
- Re: [BEHAVE] proprietary implementation v.s stand… Dan Wing
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… mohamed.boucadair
- Re: [BEHAVE] proprietary implementation v.s stand… Mark Andrews
- Re: [BEHAVE] proprietary implementation v.s stand… mohamed.boucadair
- Re: [BEHAVE] proprietary implementation v.s stand… Andrew Sullivan
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] proprietary implementation v.s stand… Reinaldo Penno
- Re: [BEHAVE] proprietary implementation v.s stand… Simon Perreault
- Re: [BEHAVE] draft-xu-behave-nat-state-sync-00 Dan Wing