Re: [BEHAVE] draft-xu-behave-nat-state-sync-00

[Dean Cheng <[e-mail]>]

Thanks for the information. From the data structure below,
I can roughly tell how the states are maintained (including
updates, timeouts, insertion, deletion, etc.). But what
I'm looking for is the mechanism (the protocol) used between
routers to exchange states, and particularly, with 
reliability for the synchronization. Can you help find
that information?

The proposal we made in this regard is to use SCSP (RFC2334)
where state synchronization is accomplished by a reliable
flooding mechanism, which has been used by all link-state
based routing protocols for years.

Cheers
Dean

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Jan Melen
> Sent: Wednesday, November 25, 2009 11:57 AM
> To: Dean Cheng
> Cc: [e-mail]; [e-mail]
> Subject: Re: [BEHAVE] draft-xu-behave-nat-state-sync-00
> 
> 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf
> > Of
> >> Jan Melen
> >> Sent: Sunday, November 15, 2009 6:38 AM
> >> To: <[e-mail]>
> >> Cc: [e-mail]
> >> 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, <[e-mail]>
> >> <[e-mail]
> >>> 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 : [e-mail] [mailto:[e-mail]] De la
> >>> part de Brian E Carpenter
> >>> Envoyé : vendredi 13 novembre 2009 02:55
> >>> À : [e-mail]
> >>> 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
> >>> [e-mail]
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/behave
> >>
> >> _______________________________________________
> >> Behave mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/behave
> >
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave