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
>