From nobody Wed Apr 21 23:01:34 2021 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA183A136C; Wed, 21 Apr 2021 23:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnlqoivoZlkg; Wed, 21 Apr 2021 23:01:25 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30082.outbound.protection.outlook.com [40.107.3.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2333A1369; Wed, 21 Apr 2021 23:01:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MtMQvu2Hw5rfFi4xs1qb3Ui+qOzw+mtKsDxdzAC+MfSwsgXuNDcEWfc2hagvio4+ayHNLR3Ltu9vCR24jHw/bB2aTOZiKVnS/xLaeVT0uSe7ZLALFhtNgvBOXmyt2kTh/j9FQbVK32Gd00VyIJT4vcvnHonGbtAiZos/Lws1yjjFgXeBBzdAtYpDJENgMBz3Df4/xU4CqY0hYOIAB+DNssXKT9W0DabH+p14mC4b+k8jNSqU2+gZ7dL998lgMeOBzvc9L/VxOrEYO0J1nE5eJeWvH/Z6Hr0b/ZCykteyFn9zpDRyAw7dnex9NR0IqDm+hkFABIX+Udx8YTRjl4NQWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xT9Wb0MeUt8+/GwyDUkpak8NCWxA4fDwzH4yw/8k5AI=; b=DCI6sP/kmk7z3F2IzGLd4eFARGO4HZZzO570xmJ1+0D2iQ61+1AUaDtVoBo/k8GGuSkIylJPwoTusO/alaXv7aW3ZolF48citdGSMDQhzlmNpjyefTSdRxS0Qild1P2ivZMQD7I5QNhPVd4jhTKP3sfUXdstle2dKmutesJTAqxO7+bRFEdcmqxBGDe4ZgIGiI+UMpTIw1o2OJAjba0k4Cn8Vn7P4yoxpOoH8NWTSS+EdSK1sF+Q0yfCe201qknT8zREIg+ZhaX0xlTbb/+qafS5NvPFASDPCXYbzHhI8PWfgNylv7WmuYGXG/5+rlzRifHb9ulegxqD5I+hYI/7bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xT9Wb0MeUt8+/GwyDUkpak8NCWxA4fDwzH4yw/8k5AI=; b=I3PsXiR3MBOhSgdoS0StrtcXhbVg43/dLmydqBSObt7x9h17y4fJM8k4f7IAeuNMIl2b23020eMgIic+Ol3Ba0c0zjwGShq8WGjPLJw2Wz7/GktvD1rGchTEfr3cmgZOmcsm19E+6wFefVbHKLDyphF+fRwIXWOleA0dxNNjZaY= Received: from AM0PR07MB4066.eurprd07.prod.outlook.com (2603:10a6:208:4d::18) by AM9PR07MB7201.eurprd07.prod.outlook.com (2603:10a6:20b:2d0::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Thu, 22 Apr 2021 06:01:18 +0000 Received: from AM0PR07MB4066.eurprd07.prod.outlook.com ([fe80::f155:daca:1b59:fe26]) by AM0PR07MB4066.eurprd07.prod.outlook.com ([fe80::f155:daca:1b59:fe26%7]) with mapi id 15.20.4087.018; Thu, 22 Apr 2021 06:01:18 +0000 From: Claudio Porfiri To: "draft-ietf-tsvwg-natsupp.all@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: Alternative proposal for nat support of SCTP Thread-Index: Adc3O53JXqFzGUF0RIqHjSs0CCQliA== Date: Thu, 22 Apr 2021 06:01:17 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.151.178.155] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 066b7307-4b58-4596-c32f-08d905540ba6 x-ms-traffictypediagnostic: AM9PR07MB7201: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +UHENYHPQ6zf2ef8auMHdQFABhkVZ+aRZaVHimL9X+8cEwvdkc5JmRVe69LCLGRmyHorR5Stb8qU2T4ZxpS2CejZPaBWNaApKvbMloDJ64Gw7aDPpI0tR0Ze0eYoEQAdHYQVwuQMTraKYcxKcPVYSgZ/SFi+HJTDe3ESkOBx6jY0wjj6lxyWYdAhR4wFVpQByB9WyeaimkplmiYhEzUqhNrld7FyQPfxWyErBkPhyS0EN5u/Bm9icSWP3E5jBzPvm/leuBEa+kVbKAp3xyqoy86sM2gwwcm4sbWLkescEWIDBpR4XYGhtKGWouICandO21n1OYX7l52W6Tbl020sabFwrVdH2XhkLrLJYWBPVYaZeBfZjMIxBiVO/5JQNZkrsY/dtPRNTDXSGWgi6LBxapiSF/bY8PNmIG4IvkgUAElbtUuPt7fkOMfO+X0VNYUQWF8t1s+l7WW0TprdwLdq+QbSD8ETCLYo+afWBBeZCICNC/IqMEkv4IbHd74TIOxeDXb25/ye7MXVCrou99raL4ytV9pNOPKoFHE831aqer74cX9/b1tuUDb9T+Gg/vK9NSBFqzAmR15ycHzoXBr0rXBdeoHqPOkP31fyT60Vbn7wy/H2TxEaqKPveLaSgjHzo4avP+aoo5aVsLlQPRvRcbIvSDlCj0XvEunLGKZ7z2etlXEPrCi8s+H6mtndRfnV x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4066.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(136003)(39860400002)(346002)(99936003)(66446008)(71200400001)(66946007)(26005)(186003)(86362001)(6506007)(45080400002)(4326008)(64756008)(66616009)(33656002)(66476007)(76116006)(5660300002)(122000001)(478600001)(52536014)(316002)(83380400001)(450100002)(66556008)(6916009)(2906002)(15974865002)(7696005)(44832011)(9686003)(30864003)(8676002)(8936002)(55016002)(38100700002)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?bm5AF9oyIrKH6bAikr3GSQxLW1aY0p3AntDu6b+tgxSXCCGd29tr+/ZnjB1e?= =?us-ascii?Q?01gzmrkmR3W4HKxBSdukCASkfh2g/CQe4IjU6/CoHDGM0+BEV5leE7hUQTbp?= =?us-ascii?Q?hhILIqFUgO/huDy7kyCXo7DmvVQC5bt5enUmmnI0pIb3Lq/OG7/riA60V74O?= =?us-ascii?Q?comDJklu10088vP+zj+t2CZ7e9y7Zb8+oQ2xTup4gmHG7kdDpmvVh4lW8PO/?= =?us-ascii?Q?K0I1HojUhs1PMLCLzFMaHMUFDjbJdCLK4omMAP+MUeHC9C9iPemp37F/Ize+?= =?us-ascii?Q?s/QZfyl10uv9o4TYwC8dj+ycO/K2zIvOtVcrNfVbmNUZSc7TTrwWP5FKI8eo?= =?us-ascii?Q?6lTneCZklZGAW6dfdVkaqx0XAOIB+RtYtbgTBGl2BfsK5T9VlxQHZ+TFEHke?= =?us-ascii?Q?mS2XGGUEUpN8l9+OU2U+YxGAP5jcwliSKkmgwnGkzO2BFyjB4qZIDCV9cVzT?= =?us-ascii?Q?GZS7EAnzInEwSNMo91qwvqvVyEBmvLhgv3btrD0uplwPjursLuKwfZTzxcRR?= =?us-ascii?Q?RmCH044Z8ZYVgAwCPPGiC5EMWogRZziNyX0vmkDIfnMAzLvdhCDkKDRBTzUe?= =?us-ascii?Q?OD3y1u0qa3MMMRA2HKuOl7Dnw7m1OJXmSPF/aW9Du+gEaRJ5Y/1aOVOZBySf?= =?us-ascii?Q?oLGCNuoA1ImGCJVxSQO4q56rxDLLXZKjXHPg7PO+WftDTYaUKVqrdml02WvS?= =?us-ascii?Q?xncZXxiiHapRJo3WQqZjxfQjDPmnbAk4DSDtBjniNZuK0xGZptuhFK4EsnCO?= =?us-ascii?Q?ir5D5mRvmC173+SsDoxJ4L3WC2h6Gi5Tr6SK1uxjxDLNrvFOHYibxr9TK2wk?= =?us-ascii?Q?MGGxNhufJ4u1kOHd5odOrgsX6XqOMUDS+AIptMhcSpt9SSfj1PKbKBjGCLr1?= =?us-ascii?Q?/6hhrjny7JWAR1Yytz9Q/wepTRn70awLtUZ23wtt5tqEQ595+VA4su3usyPk?= =?us-ascii?Q?bOhLjvxcZ5ukRaeVnaz1Bv3JcJ4oh2KTOgegiBS+rbsJt741V1r9hGxgCizA?= =?us-ascii?Q?8NympA54ZAdbVXDLSCP0DQRQViF2Z0K+h72ulGUC65UkDtGdtb8L3pZ45/GW?= =?us-ascii?Q?eJQ3xR7/mQ+STyPn5mX3lKVLEehjfa0oZRc38fno836WkAum2Pcdmx0+ht96?= =?us-ascii?Q?XjEHjh78SdU6xugwCIf/xFreFiAu9kGlma7x+7RWQ9EFFmXzl9hq01THESyY?= =?us-ascii?Q?a3B/gmFJZ8+aKhoXI/naMlo4fco2ytUdq9S600SQO2/Rp5/BQbT56adsZFLE?= =?us-ascii?Q?ZOEuimgXwGdra2JIFVSy8AiRp8Qxk78qeD6r0a+V+HammDlybie2aDR7FTCs?= =?us-ascii?Q?E+NA2p/L18jzuDn3Nr9kRM4q?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01D7374D.ABB208A0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB4066.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 066b7307-4b58-4596-c32f-08d905540ba6 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2021 06:01:17.9756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dtOQhFrdgH9KCcXkzOV/TS0rKaRrXjr110p07FYgppHxIl/9QoRy8FLymSeU0y9YVeY3DlYCh/ktfUO9EmjQci3UabQ46U+TSXcVkspL5sI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR07MB7201 Archived-At: Subject: [tsvwg] Alternative proposal for nat support of SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 06:01:32 -0000 ------=_NextPart_000_0052_01D7374D.ABB208A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, the AD Review to draft-ietf-tsvwg-natsupp-22 has shown some room for improvements. I'd wish to propose an alternative approach for supporting SCTP in scenarios where NAT and Load Balancers exist. Please consider my proposal as a way to enhance SCTP and reduce the complexity of previous proposals. With best regards, Claudio Porfiri. - Background This proposal is an attempt to solve some of the issues raised in the review of the current draft-ietf-tsvwg-natsupp-22. It also deals with implementation of nodes that adopt SCTP as transport protocol in a Cloud environment, mostly in containerized way, that exploit NAT for redundancy and scalability reasons: the SCTP Endpoint in those environment is ditributed among SCTP Hosts that expose the same Port but from the network the SCTP Termination is seen as belonging to a single host. Often those distributed SCTP Endpoints are multihomed. A typical example is the AMF node in 5G networks, related to the NG-C interface, (3GPP TS 38.412, TS 38.413), a similar case is the MME node in 4G network, related to the S1-MME interface (3GPP TS 36.412, TS 36.413). A NAT supporting SCTP must also be able taking care of simpler scenarios such as SCTP Clients behind a NAT wishing to create Associations towards the same remote peer, even cases where multiple NAT exist and/or a transversal scenarios where independent NAT devices deal with the same Associations in single or multihomed cases. The case where NAT implements port-forwarding also needs to be considered. The scenario called Multipoint Traversal is possibly the most complex when distributed SCTP Endpoint, this cannot be neglected in a SCTP NAT support solution. - Cornerstones of the proposal As in draft-ietf-tsvwg-natsupp-22, the main requirement towards NAT is that handling of the SCTP ports is to be kept at the SCTP Endpoint, thus the NAT devices shall never change SCTP source or destination ports. In case of collision, it's the source SCTP Endpoints that will take the decision about adopting a different source port. The NAT devices will only need to inspect the SCTP common Header of the SCTP packets, all decisions are based on [Source-IP:Source:Port;Destination-IP:Destination-Port] and VTAG. The reason why VTAG is read is to check that it's equal to zero, as this means that the packet transports an INIT chunk. - Advantages towards natsupp draft version 22 The proposed approach doesn't need the NAT devices to take care of VTAG handling. The NAT device only needs local rules for creating a NAT Table entry as it doesn't need to trace the Association establishment. The NAT table entries are only depending on a timer supervision, not on Association state. There's no need for synchronization among NAT devices, consistency of NAT Tables among different NAT devices is kept automatically even in cases of restarts. NAT doesn't parse SCTP packets, thus NAT behavior doesn't depend on SCTP. The NAT device doesn't need to send any SCTP packet to the SCTP Endpoints. Decisions at the SCTP Hosts are taken by means of interpreting the retransmissions and the timeouts, collisions are solved by the client by choosing a different port numbers rather than a different VTAG. - Disadvantages towards natsupp draft version 22 Handling of multiple Associations between the same SCTP Endpoints are not possible (this is not permitted by RFC 4960 On the same source and destination port pairs ). The limit of number of Association between hosts is given by the port number, it's not possible from clients behind NAT to establish more than 64k Associations towards the same remote SCTP Endpoint. Setup time for Associations in collision case takes longer. ----------------------------------------------------------------------------------------------- - Scope of the proposal The scope of the proposal is the use of NAT in networks where SCTP clients and server are instantiated with neither restrictions on the level of NAT hierarchically or horizontally, nor on the adoption of multihoming. In the scoped scenarios, NAT can be used for hiding SCTP clients, servers and for implementation of Load Balancing in the sense that multiple SCTP servers are hidden and the choice of the one serving the client is decided by the NAT function implementing Load Balancing at Association Establishment time and kept for the Association Lifetime. The proposal doesn't require VTAG handling and the related avoidance/synchronization between server instances, which the current proposal would require. The NAT only does tracking individual paths, the egressing traffic creates return paths towards each instance avoids the need for VTAG handling. Tracking is thus handled by a single mechanism that is needed for all cases to deal with multiple SCTP endpoints sending traffic towards the same remote address. The following basic scenarios are considered 1) +-------+ [SCTP client C1]----------+ | [SCTP client C2]----------+ NAT +----- [SCTP client C3]----------+ | +-------+ Where SCTP Hosts implementing SCTP Endpoints C1,C2,C3 behave as pure clients, single-homed 2) +-------+ [SCTP server S1]----------+ | [SCTP server S2]----------+ NAT +----- [SCTP server S3]----------+ | +-------+ Where SCTP Hosts implementing SCTP Endpoints S1,S2,S3 behave as servers, single-homed 3) +-------+ [SCTP server S1]----------+ | [SCTP server S1]----------+ LB +----- [SCTP server S1]----------+ | +-------+ Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving as a server, single-homed 4) +--------------+ +-------+ | + | | |SCTP client C1+----------+ NAT +----- | +----+ +--+ | +--------------+ | | +-------+ | | +--------------+ | | +-------+ | +--- |--+ | | |SCTP client C2| +-----+ NAT +----- | +----------+ | +--------------+ +-------+ Where SCTP Hosts implementing SCTP Endpoints C1,C2 behave as pure clients, multi-homed 5) +--------------+ +-------+ | + | | |SCTP server S1+----------+ NAT +----- | +----+ +--+ | +--------------+ | | +-------+ | | +--------------+ | | +-------+ | +--- |--+ | | |SCTP server S2| +-----+ NAT +----- | +----------+ | +--------------+ +-------+ Where SCTP Hosts implementing SCTP Endpoints S1,S2 behave as servers, multi-homed 6) +--------------+ +-------+ | + | | |SCTP server S1+----------+ LB +----- | +----+ +--+ | +--------------+ | | +-------+ | | +--------------+ | | +-------+ | +--- |--+ | | |SCTP server S1| +-----+ LB +----- | +----------+ | +--------------+ +-------+ Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving as a server, multi-homed 7) Any complex scenario built with those such as: +-------+ [SCTP client C1]----------+ | [SCTP client C2]----------+ NAT +-----+ [SCTP client C3]----------+ | | +-------+ | +------+ +----+ | [SCTP server S1]-----------------------------+ LB +------- IP A [SCTP server S1]-----------------------------+ | +-------+ +-------+ | [SCTP client C4]----------+ | | +------+ [SCTP client C5]----------+ NAT +--+ +----+ | +--------------+ | +-------+ | +-----+ |SCTP server S2] +-------+ | +----------+ | |--------------+ | NAT +------------------------- IP B [SCTP client C6]----------+ | [SCTP server S4]----------+ | +-------+ In the example above clients C1, C2, C3, C4, C5 and servers S1 and S2 share the same external IP A, client C6 exploits the external IP B and server S3 is multihomed and exploits IP A and IP B. Server S4 exploits IP B as well. Server S1 and S2 are seen as a single, distributed SCTP Endpoint, NAT LB does inspect Association requests and assigns the serving SCTP host based on a Load Sharing algorithm. ---------------------------------------------------------------------------------------------------- ----- It's important to state that unless being part of a SCTP Distributed Endpoint, the port number used when defining the SCTP Endpoints of a SCTP server behind a NAT need to be unique. - What is kept from the draft natsupp v22 Similar to what described in the current draft-ietf-tsvwg-natsupp there's the need of a cooperation between SCTP Hosts and NAT device in order to allow Association setup and traffic exchange. The NAT devices will take a lookup table that is meant to keep the state of the Association limited to what is needed in NAT. NAT has a functions for searching the lookup table and take a decision based on the results. The SCTP Endpoint takes the responsibility to take decisions based on the feedbacks received from the network in order to setup the Association. An Association is established towards the primary peer interface first, then the other paths that belong tp a multihomed association are added by means of ASCONF messages. The following extensions are taken (Only needed for Optional Part) ----------------------------- Extended ERROR Chunk 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Reserved |M|T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / zero or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ERROR chunk defined in [RFC4960] is extended to add the new 'M bit'. The M bit indicates to the receiver of the ERROR chunk that the chunk was not generated by the peer SCTP endpoint, but instead by a middle box. ---------------------------------------------------------------------------------------------- Proposal in details ---------------------------------------------------------------------------------------------- The NAT functionality takes care of SCTP packets in EGRESS meaning that the SCTP packet is originated from an SCTP host that is located behind the NAT itself, as well as SCTP packets in INGRESS meaning that the SCTP packets are originated from the external network. NAT learns about Associations by inspecting the SCTP Header only, it has knowledge of [Source.IP:Source.Port;Dest.IP:Dest.Port]; a timer supervision exists at association level that removes the Association information from the NAT after a timer expires. NAT needs to recognize INIT chunks, this is achieved by looking at SCTP header since INIT must be transported in a SCTP packet with VTag=0. There's no Signaling between NAT and the SCTP host, rather SCTP host understands the NAT behavior as it will experience retransmission faults when the NAT device cannot forward the SCTP packets. In details, the implementation of what proposed in this paper allows: * Client in NAT environment to establish multihomed associations towards remote Servers * Server in NAT environment to establish multihomed associations from remote Clients * Client or Server in NAT environment to establish multihomed associations towards legacy RFC 4960 peers * NAT devices to cope with multihomed SCTP traffic * NAT devices to cope with restart (with limitations) Limits of the proposed paper are described below: * Network Address and Port Translation (NAPT) is not supported. * Limited amount of possible association towards the same remote host (16 bit). * Restart in NAT devices under some circumstances can go in race condition. * Limited interwork with legacy SCTP Host * Multiple Associations between the same SCTP Endpoints are not supported NAT device SCTP specialization ============================== NAT need to implement NAT forwarding table for SCTP containing the information related to SCTP Association as well as the forwarding. NATTableEntry ::= [Source.IP:Source.Port;Dest.IP:Dest.Port;fwd.IP;NATTimer] Since Distributed SCTP Endpoint is supported, there are NAT that have multiple choices for forwarding packets, i.e. there are multiple hosts having an SCTP Server at the same SCTP Port. SCTP Parsing ------------ In order to handle SCTP packets, NAT needs to discriminate packets containing an INIT chunk. This is achieved by checking the Destination VTag in the SCTP Header, because SCTP packets containing INIT chunk have VTag = 0. Load Balancers -------------- A Load Balancer is a node in the network that hides the instantiation of an SCTP Endpoint over a set of SCTP Hosts in a local network. The Load Balancer at INIT will select one SCTP Host for handling it, the traffic related to the resulting Association will be NATted towards the chosen host. When a INIT packet reaches a Load Balancer, there are multiple choices for the selected Dest.Address:Dest.Port, LB will select one of the SCTP Hosts that can be elected for terminating the Association. It's out of scope of this paper the description of a selection algorithm. Note that multiple choices only applies to LB devices when INIT arrives as INGRESS. SCTP control functions ---------------------- NAT implementations provide the following functions: boolean lookupNAT(Source.IP, Source.Port, Dest.IP, Dest.Port) returns TRUE if an entry in NATTable matches the given 4-tuple boolean multipleDestination(Dest.Port) returns TRUE is multiple hosts exist sharing the given SCTP port void createNAT(Source.IP,Source.port,Dest.IP,Dest.port) creates an entry at the NATTable with the given SCTP Association void forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port) locate the given SCTP association in NATTable, do NAT and forward the packet. Reset the NATTimer tied to the entry. void discardPacket(Source.IP,Source.port,Dest.IP,Dest.port) silently discard the packet for the given Association void destroyNAT(Source.IP,Source.port,Dest.IP,Dest.port) removes from NATTable the entry related to the given SCTP Association void sendINITError(Source.IP,Source.port,Dest.IP,Dest.port) sends an ERROR Chunk towards Source.IP,Source.port with parameter "INIT cannot be forwarded" Meta-code of the NAT behavior INGRESS Packets : if pkt==INIT if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) // This is congestion case, since multiple associations between the // same SCTP Endpoints are not supported, the packet is discarded discardPacket(Source.IP,Source.port,Dest.IP,Dest.port); *** OPTIONAL sendINITError(Source.IP,Source.port,Dest.IP,Dest.port); *** else if MultipleDestination(Dest.Port) // This case applies only on Load Balancers and only with INGRESS // Here LB solves the distributed Endpoint Choose a local Host according to the Load Balancer Rules // ----------------------------------------------------- createNAT(Source.IP,Source.port,Dest.IP,Dest.port); forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port); else if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port); else discardPacket(Source.IP,Source.port,Dest.IP,Dest.port); EGRESS Packets : if pkt==INIT if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) // This is congestion case discardPacket(Source.IP,Source.port,Dest.IP,Dest.port); *** OPTIONAL sendINITError(Source.IP,Source.port,Dest.IP,Dest.port); *** else createNAT(Source.IP,Source.port,Dest.IP,Dest.port) forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port); else if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port); else createNAT(Source.IP,Source.port,Dest.IP,Dest.port) forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port); NATTimer Expiration : destroyNAT(Source.IP,Source.port,Dest.IP,Dest.port); NAT behavior with SCTP packets ------------------------------ In a NAT where the HB packets are EGRESS, according to NAT behavior they can be: discarded - in such case the sender will experience rtx timeout forwarded to the right SCTP host - in this case the peer will reply with proper SCTP Chunk forwarded to the wrong SCTP host - in this case the wrong host will see an OOTB packet. In a NAT where the HB packets are INGRESS, according to NAT behavior they can be: discarded - in such case the sender will experience rtx timeout forwarded to the right SCTP host - in this case the peer will reply with proper SCTP Chunk forwarded to the wrong SCTP host - in this case the wrong host will see an OOTB packet Data Formats: ERROR Chunk New parameter : HB with Inconsistent VTag New parameter : ASCONF with Inconsistent VTag New parameter : INIT cannot be forwarded INIT Chunk Parameters: (may appear in INIT, INIT-ACK and ASCONF) IP Addresses NOT CONFIRMED SCTP Endpoint behavior ====================== An SCTP Endpoint receiving an OOTB packet will check: - If it's an HB packet, whose 4-uple is consistent with an Association established at that Host but VTags are not known, an ERROR signal "HB with Inconsistent VTag" will be sent back. - If it's an ASCONF packet with "Address 0.0.0.0" and ERROR signal "ASCONF with Inconsistent VTag" will be sent back. - A legacy RFC 4960 SCTP Host on the other hand should send an ABORT, whilst implementations exist that can be configured for silently discarding OOTB packets. An SCTP Endpoint receiving an ERROR Chunk with parameter "INIT cannot be forwarded" will check whether it has been caused by an own INIT by verifying source and destination IP addresses, ports and VTAG. In case it maps an own INIT Chunk, the SCTP Host will behave as in case of rtx timeout, otherwise that chunk will be treated as an OOTB chunk. NAT and port forwarding: we are not considering port forwarding as a valid NAT case, an SCTP Host behind a NAT that does port forwarding for that SCTP Host is the same as exposing the SCTP Host directly on the external network, in this case there's no need to change what the NAT does. In the following description we assume that all NAT and Load Balancers implement the NAT behavior as described above. The remote SCTP Host on the other hand may implement legacy rfc4960, this is considered in the Use Case description. Use Cases: Client only cases: 1. Single-homed vs single-homed Client sends INIT packet, if it does not succeed it will retry with a different Source.port number. Reason why INIT/INIT-ACK doesn't succeed is assumed to be due to a congestion in any of the NAT being part of the path between the SCTP Endpoints. 2. Single-homed vs multihomed (public IP addresses known to the multihomed peer) Client sends INIT packet, if it does not succeed it will retry with a different Source.port number. INIT-ACK packet contains a new option that indicates the list of IP addresses is NOT CONFIRMED Since the set of remote IP addresses is not CONFIRMED, client will start probing with HB. According to NAT Behavior above, the peers can experience - HB-ACK : the IP address becomes CONFIRMED - rtx timeout : the sender keep on probing that path according to RFC 4960 - ERROR "HB with Inconsistent VTag" : the IP address used for HB is permanently unavailable and the sender MAY try to probe it again after a certain time - ABORT : after checking that the ABORT has been caused by HB by checking the Source.IP, in case it's confirmed that ABORT has been caused by HB, the sender will threat it in the same mode as an ERROR "HB with Inconsistent VTag". Note that, due to the network configuration, the multihomed Association resulting may not be complete as a set of paths may be not possible to establish. 3. Multihomed vs multihomed (public IP addresses known to the multihomed peers) Client sends INIT packet, if it does not succeed it will retry with a different Source.port number. INIT packet contains a new option that indicates the list of IP addresses is NOT CONFIRMED. INIT-ACK packet also contains a new option that indicates the list of IP addresses is NOT CONFIRMED. When succeeding, since the set of remote IP addresses is not CONFIRMED, client and server will start probing with HB. The behavior of the peers is the same as described above in case 2. Same as case 2, multihomed Associations may not be completed. 4. Multihomed vs multihomed (public IP addresses unknown to the multihomed peer) This case begins as the single-homed vs single-homed case until the Association is established. The peers, independently, will start adding further IP addresses to the Association, one at a time, since the public IP address is unknown, the SCTP Host only knows the local IP addresses it can use. The SCTP Endpoint will use rfc6051, it will send an ASCONF signal with IP-address = 0.0.0.0 using one of the internal IP address as source towards a CONFIRMED peer's IP address. According to NAT Behavior above, the peers can experience - ASCONF-ACK : the IP address is added to the Association and path probing can start as in case 2. - rtx timeout : the IP address used for ASCONF is permanently unavailable - ERROR "ASCONF with Inconsistent VTag" : the IP address used for ASCONF is permanently unavailable and the sender MAY try to probe it again after a certain time - ABORT : after checking that the ABORT has been caused by ASCONF by checking the Source.IP, in case it's confirmed that ABORT has been caused by ASCONF, the sender will threat it in the same mode as an ERROR "ASCONF with Inconsistent VTag". Same as case 2, multihomed Associations may not be completed. 5. Server Endpoint vs Server Endpoint This is a special case where both Endpoint have a fixed and well-known port number that MUST be used as Source.port in the Association establishment. In such case, only one host within a NAT zone can establish one Association towards another host in another NAT zone. The Endpoint acting as Client sends INIT packet, if not succeed it will not try again but inform the application that it's not possible to establish an Association. 6. NAT restart. If a NAT restarts, the NAT table is lost and the following events can occur: An existing association keeps on sending packets on the set of paths known by the peers. According to the NAT rules, those SCTP packets will make NAT re-creating the proper NAT entries from the EGRESS traffic perspective. Race condition may happen when one sctp host will send an INIT packet that will arrive at the NAT before a traffic packet can restore the NAT entry. In such case INIT has overwritten the NAT entry that was previously used by the existing association. We see this event as very rare to happen, and the reason for it is because NAT is a blocking mechanism that doesn't provide full capacity. A multihomed configuration can help reducing the blocking probability. The race condition can be partially solved if the NAT waits for a time long enough to cope with all the associations data or HB transmissions. After that time it can be assumed that all the Associations using that NAT will have rebuilt the related entries in the NATTable. The solution would not handle INIT chunks during that observation time, after that INIT chunks can be handled. 6. Timing considerations SCTP exploits internal retransmission timers for detecting how NAT devices on the paths are acting and uses timeouts in order to take decisions on how to setup the multihomed association. Here, the shorter the timers the quicker the setup procedure, still assuming that the initial setup can go into collision a number of times it may take a significant time to setup associations. RFC 4960 provides a set of recommended values to be used for timers and retransmission attempts, the adoption of those timers would need to be reconsidered in the scope of the current paper. The current paper has a simple state machine at the NAT devices based on a supervision timer, this is possible because SCTP sends traffic over all the paths at least at HB timing rate for path probing. Every time an SCTP Packet is forwarded, NATTimer is restarted. The choice of NATTimer value SHOULD ensure that there are no rtx timeouts due to NATTimer expiration, in fact NATTimer needs to cope with the slowest traffic case that is path probing, is then recommended that NATTimer is larger than 2 times HB timer, but at the same time NATTimer must release a path as soon as it's not being used by an active Association, this would suggest a value that is as short as possible. A good compromise seems to be 2 * HB timer < NATTimer < 2 * HB timer. 7. Association setup improvement (Optional) It is possible to improve the setup time for an association if NAT device could help SCTP host to take a quick decision in case of collision. This feature is optional and MAY be implemented at the NAT device, whilst handling is mandatory at the SCTP host. When a NAT device will receive an INIT chunk, it will check whether it can be forwarded by inspecting the NAT lookup table. If it cannot be forwarded, it MAY send an SCTP Packet containing an ERROR Chunk with parameter "INIT cannot be forwarded". Since no association exists yet, and because VTAG=0 cannot be used, the NAT device need to parse the received INIT chunk and retrieve the Initiate Tag that will be used as VTAG. ==================================================================================================== ======================== Ericsson Claudio Porfiri System Developer Developer BNEW DNEW NSV PPA RAN Infra Architecture Mobile: +46761498209 claudio.porfiri@ericsson.com Ericsson Isafjordsgatan 14E 164 80,Stockholm Sweden Our commitment to Technology for Good and Diversity and Inclusion contributes to positive change in the Networked Society. Follow us on: Facebook LinkedIn Twitter Legal entity:ERICSSON AB registration number 556056-6258, registered office in This communication is confidential. Our email terms www.ericsson.com/en/legal/privacy/email-disclaimer ------=_NextPart_000_0052_01D7374D.ABB208A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR9DCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7jCCA9agAwIBAgIPAXRysiUjsN1oq9rSC0W8MA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDA5MDkxMTQ4MjlaFw0yMzA5MTAxMTQ4 MjlaMFoxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9DbGF1ZGlvIFBvcmZpcmkxKzApBgkq hkiG9w0BCQEWHGNsYXVkaW8ucG9yZmlyaUBlcmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDR4uao11SfFGh/STjjLuVJkJeCI0BnA3uK1aYOWtwHB6GOdqK7guqrtZ6k Ro9ZdUEjm4IZZS9+ceiLJ9zqjI8IPueSfc20YLr85gsGvoRunbznuYEjtGVa5q4LurWnSWztU65s aB0sjA7pYzePEh2OwTsEmpuPoj+UTlZ74Qtqet2Frd5fBJM4UIOIBUmAkJzhBIH0YPvi5BpckBM9 UVGMZG2RQfcg8FjD0rWrDR0tuQ8wfRT92BSzy+HN5LQ/sKpiPm4epR6EltPZ4naf+z3/DEjncpr4 xbWW3rw7UNXmbNxRrSAWxZsSxV9wVhgpWJvvw8OxfT3oGxkEwZ/1D21VAgMBAAGjggHCMIIBvjAf BgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAdBgNVHQ4EFgQU+EHaqoziZDMJnoFfItSX 13b5n2YwDgYDVR0PAQH/BAQDAgWgMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYB BQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCcGA1Ud EQQgMB6BHGNsYXVkaW8ucG9yZmlyaUBlcmljc3Nvbi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYc aHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEB CwUAA4ICAQCBh1mArStVknKHd4Gx4E/ruY7Ra9rhX0FDaLuN4kmEHm2cyOObweiyXzHCa0EiM5MW jiX75i/2Pi2leiwBAmtjdEgZ4LGQNJFwB40xoeYHnIl65y12Fw9OtYWcWVWoBbFlXE2YVgv9JNeU /L2Sy/MaPbLx6brV1U4nw3OkLcRwI6nrQAKxbKE8PU978ubLlNLWZ/TaSYb1L3PTW2WDp5OiS2Jd ZrbtAt+s9sD70oum3SVxcQPy6kH6V2bz0/dtYAi2f/rGQHWyp8RQK9qsGK+RC1yc54kgwua9ohKg S7VBdRsyLowa1EeyWz4Uf3whZSXEh/AdaYb3A/AmkMHunzyyPsAaomibziAma5WQqgubSdX02VTe vZaBpytyjZ+2Bdoy57IHR4qyba4Yj4+X18960HOsoF0aiHwBlbGK06Sp4MjvAYWcsFmC3/tLyb+O SxEaWbXMmJP531hqTS7G1Hd1c62RpH/HBaOG+74EyJXxAhlFh5uAWFInpGnwcXTRfSyiz6eDQWZW B+SZl9QfMPmGjaBOMegvok55CISaN3nwvmAQUz3ahouQz4m31pYHSODQJ9Brb0BLPox8CEFuA1lp VsJ4nN82f9E6ekIOC654vwrSuRknRuvoOAlFPX0bhhd2srpCVhkhEcFySrlbN4Sre1HUM3jwXk+7 y5bz/bCo0DCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcN MTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3 DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz 2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY 7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2 PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0 XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U 5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5 LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77 /NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffY LtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEF BQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRw Oi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsG AQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNV HR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29u ZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WP mpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLE GOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX 9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy 50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8 5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P +UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdW OaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqo kUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDk ZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAv8wggL7AgEBMFowRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzAg8BdHKyJSOw3Wir2tILRbwwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNDIyMDYwMTE2WjAjBgkqhkiG9w0BCQQxFgQUMxXDquM/ tOqs8PuTDKeoPXiXeBUwQwYJKoZIhvcNAQkPMTYwNDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowaQYJKwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJT RTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg djMCDwF0crIlI7DdaKva0gtFvDBrBgsqhkiG9w0BCRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8B dHKyJSOw3Wir2tILRbwwDQYJKoZIhvcNAQEBBQAEggEATTS6PVGxa5GmEM/qqJy8cuvy4ZOa8vev OLMVDlHVPBvDrGVJMe4ZVfGo6tvSVYo5wevl81G3Aka6dYjxZcaJ1fYasz7tzhVBOnna8BY+pYJo YzBp4plolbv+02emKoCOgwX6tGLSXg0i+8A2G2t6wJnXoE4ZXyHhqdHBdEb3PLoTN4ia+oMSsZ08 i2Z2gha5wL7Gesc/fJO8OOPD300ljMCN5AWq6u8VH0zUW+wEuqqzpQ/FS1omqi4pl1o4ZTucsUz9 hCPwPae+OYS34vx61iKcpuHtc0aNH9EyRWdPrakDSmh7QmkHwe6zYuUintgCQ09rUUkcT+xAbf6u uabtuwAAAAAAAA== ------=_NextPart_000_0052_01D7374D.ABB208A0--