From nobody Sat Apr 24 05:19:50 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 43EEF3A0B12; Sat, 24 Apr 2021 05:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 DCywV2mA0YLp; Sat, 24 Apr 2021 05:19:44 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788533A0B07; Sat, 24 Apr 2021 05:19:44 -0700 (PDT) Received: from m1.fritz.box (ip4d15f626.dynamic.kabel-deutschland.de [77.21.246.38]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 703387C389382; Sat, 24 Apr 2021 14:19:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Michael Tuexen In-Reply-To: Date: Sat, 24 Apr 2021 14:19:33 +0200 Cc: "draft-ietf-tsvwg-natsupp.all@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <03142829-58F8-4276-96DD-CCA0CF782737@lurchi.franken.de> References: To: Claudio Porfiri X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [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: Sat, 24 Apr 2021 12:19:49 -0000 > On 22. Apr 2021, at 08:01, Claudio Porfiri = wrote: >=20 > 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. Hi Claudio, the authors of draft-ietf-tsvwg-natsupp-22 have never stated that the = document describes the only way to do NAT for SCTP, but is describes one way. There are = definitely other ways to do it with different pros and cons. Regarding your proposal, see my comments in-line. Best regards Michael >=20 > With best regards, > Claudio Porfiri. >=20 >=20 > - 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). >=20 > 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. I'm not sure what you mean by referring to 'port-forwarding'. If you = refer to a way to add manually specific entries into the NAT binding table, then it is fine. = But we haven't specified that. If you refer to a way to change port numbers of packets processed = by the NAT function, then this is not covered by NAT variant described in = draft-ietf-tsvwg-natsupp. >=20 >=20 > The scenario called Multipoint Traversal is possibly the most complex = when distributed SCTP > Endpoint, this cannot be neglected in a SCTP NAT support solution. >=20 > - 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. In my view an SCTP end-point can not change its local port number. It is = a property of the end-point. Looking at the socket API (which is only informational, I understand = this), you can't "re-bind" an end-point. You either call bind() explicitly once or it is called = implicitly when you call connect() or sendto(). So in your case you would have to fail the association setup in case of = an internal port number collision. The question is if the probability of this failure is acceptable. My = understanding is that NAPT was introduced to deal with local port number collision, since it was = considered too likely. That is the whole reason why we introduced the method described in = draft-ietf-tsvwg-natsupp. The 4-tupel consisting of both port numbers and port v-tags are used as a connection = identifier. If failing SCTP association setups in case of local port number = collisions is acceptable, then the methode described in draft-ietf-tsvwg-natsupp is not needed. > 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. That is definitely simpler than what is required for = draft-ietf-tsvwg-natsupp. >=20 >=20 > - 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. I don't think draft-ietf-tsvwg-natsupp describes any synchronization = methods between NAT functions. >=20 > NAT doesn't parse SCTP packets, thus NAT behavior doesn't depend on = SCTP. I agree that your description does not require any chunk processing of = SCTP packet, but is does need to understand the SCTP common header (you refer to the verification = tag). So the NAT does need to understand SCTP and act in an SCTP specific way. > 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. I don't understand that. An SCTP end-point can not change its local port = number. A client application can retry connection setups. But how does the client application know = that it has to retry with a new end-point compared to the peer end-point is not available or there = is some temporary network outage? >=20 > - 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 ). And I wouldn't consider this a disadvantage. It is just a consequence of = the way local port number collisions are handled. I think handling of local port number collisions = is important (I think we disagree here), but I don't think more than one association between = two end-points is=20 feature which is required. > 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. That is fine. I don't think any NAT variant must improve this limit. > Setup time for Associations in collision case takes longer. >=20 > = --------------------------------------------------------------------------= --------------------- >=20 > - 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. I think load balancers are different from NAT function. A load balancer, = in my view, gives a single point of contact, but the actual traffic is managed by multiple other = nodes. This is similar to an any-case service. A good way to deal with this = would be that the clients would send the packets containing the INIT chunks to the IP address of the = load balancer. The load balancer would decide, which endpoint should deal with this particular = association (the algorithm does not need to be specified and I'm sure there are already a bunch of methods = with IPRs). Then the actual end-point would send back an INIT-ACK with a specific parameter = indicating the this INIT-ACK belongs to the INIT which was sent to the address of the load balancer, but that = particular address will not be used anymore. This way the load balancer is not involver in the = actual communication anymore. >=20 > The proposal doesn't require VTAG handling and the related = avoidance/synchronization between server > instances, which the current proposal would require.=20 > 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. >=20 >=20 > The following basic scenarios are considered >=20 > 1)=20 > +-------+ > [SCTP client C1]----------+ | > [SCTP client C2]----------+ NAT +----- > [SCTP client C3]----------+ | =20 > +-------+ =20 > Where SCTP Hosts implementing SCTP Endpoints C1,C2,C3 behave as pure = clients, single-homed=20 >=20 > 2)=20 > +-------+ > [SCTP server S1]----------+ | > [SCTP server S2]----------+ NAT +----- > [SCTP server S3]----------+ | =20 > +-------+ =20 > Where SCTP Hosts implementing SCTP Endpoints S1,S2,S3 behave as = servers, single-homed=20 >=20 > 3) > +-------+ > [SCTP server S1]----------+ | > [SCTP server S1]----------+ LB +----- > [SCTP server S1]----------+ | =20 > +-------+ =20 > Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving = as a server, single-homed I do see that different from NAT. There is no NAT necessary for this, = just an address change during the handshake. >=20 > 4) >=20 > +--------------+ +-------+ > | + | | > |SCTP client C1+----------+ NAT +----- > | +----+ +--+ | > +--------------+ | | +-------+ > | | > +--------------+ | | +-------+ > | +--- |--+ | | > |SCTP client C2| +-----+ NAT +----- > | +----------+ | > +--------------+ +-------+ > Where SCTP Hosts implementing SCTP Endpoints C1,C2 behave as pure = clients, multi-homed=20 >=20 > 5) > +--------------+ +-------+ > | + | | > |SCTP server S1+----------+ NAT +----- > | +----+ +--+ | > +--------------+ | | +-------+ > | | > +--------------+ | | +-------+ > | +--- |--+ | | > |SCTP server S2| +-----+ NAT +----- > | +----------+ | > +--------------+ +-------+ =20 > Where SCTP Hosts implementing SCTP Endpoints S1,S2 behave as servers, = multi-homed=20 >=20 > 6) > +--------------+ +-------+ > | + | | > |SCTP server S1+----------+ LB +----- > | +----+ +--+ | > +--------------+ | | +-------+ > | | > +--------------+ | | +-------+ > | +--- |--+ | | > |SCTP server S1| +-----+ LB +----- > | +----------+ | > +--------------+ +-------+ =20 > Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving = as a server, multi-homed >=20 > 7)=20 > Any complex scenario built with those such as: >=20 > +-------+ > [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] +-------+ =20 > | +----------+ | > |--------------+ | NAT +------------------------- IP B > [SCTP client C6]----------+ | > [SCTP server S4]----------+ | > +-------+ >=20 >=20 > 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. >=20 > 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. Except the the LB, one can argue which scenarios need to be supported. = But, except LB, all of them are fine. >=20 > = --------------------------------------------------------------------------= -------------------------- > ----- >=20 > 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. That is the fundamental difference between your proposal and the one in = draft-ietf-tsvwg-natsupp. draft-ietf-tsvwg-natsupp does assume that handling of local port number = collisions is required, whereas your proposal does assume that it is not required. > - 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. >=20 > The SCTP Endpoint takes the responsibility to take decisions based on = the feedbacks received from > the network in order to setup the Association. >=20 > 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. >=20 > The following extensions are taken (Only needed for Optional Part) > ----------------------------- >=20 > Extended ERROR Chunk >=20 > 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 =3D 9 | Reserved |M|T| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ \ > / zero or more Error Causes / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 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. >=20 > = --------------------------------------------------------------------------= -------------------- > Proposal in details > = --------------------------------------------------------------------------= -------------------- >=20 > 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=3D0. > 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. >=20 > 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) >=20 > 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 >=20 >=20 >=20 > NAT device SCTP specialization > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > NAT need to implement NAT forwarding table for SCTP containing the = information related to SCTP > Association as well as the forwarding. > NATTableEntry ::=3D = [Source.IP:Source.Port;Dest.IP:Dest.Port;fwd.IP;NATTimer] >=20 > 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. >=20 > 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 =3D 0. >=20 > 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. >=20 > SCTP control functions > ---------------------- > NAT implementations provide the following functions: >=20 > boolean lookupNAT(Source.IP, Source.Port, Dest.IP, Dest.Port) > returns TRUE if an entry in NATTable matches the given 4-tuple >=20 > boolean multipleDestination(Dest.Port) > returns TRUE is multiple hosts exist sharing the given SCTP port >=20 > void createNAT(Source.IP,Source.port,Dest.IP,Dest.port) > creates an entry at the NATTable with the given SCTP Association >=20 > 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. >=20 > void discardPacket(Source.IP,Source.port,Dest.IP,Dest.port) > silently discard the packet for the given Association >=20 > void destroyNAT(Source.IP,Source.port,Dest.IP,Dest.port) > removes from NATTable the entry related to the given SCTP = Association >=20 > 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" >=20 >=20 > Meta-code of the NAT behavior >=20 > INGRESS Packets : > if pkt=3D=3DINIT > if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) =20 > // 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); Doesn't this mean that a retransmission of an INIT chunk is not = possible? So if for whatever reason the first packet of an association containing an INIT chunk is = dropped in the network, the whole association setup fails? > *** 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 =20 > // Here LB solves the distributed Endpoint > Choose a local Host according to the Load Balancer = Rules=20 > // = ----------------------------------------------------- > 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); >=20 >=20 > EGRESS Packets : > if pkt=3D=3DINIT > if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) // This = is congestion case > discardPacket(Source.IP,Source.port,Dest.IP,Dest.port); This means that a local port number collision results in permanent = packet loss for the INIT chunks. For the end-point this looks like a long term network = outage. > *** 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); >=20 > NATTimer Expiration : > destroyNAT(Source.IP,Source.port,Dest.IP,Dest.port); >=20 >=20 > 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. Why would a packet be delivered to the wrong SCTP host? Destination = addresses are not translated. >=20 > 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 Why would that be a wrong entry in the NAT binding table? >=20 >=20 > Data Formats: >=20 > ERROR Chunk > New parameter : HB with Inconsistent VTag > New parameter : ASCONF with Inconsistent VTag > New parameter : INIT cannot be forwarded >=20 > INIT Chunk Parameters: (may appear in INIT, INIT-ACK and ASCONF) > IP Addresses NOT CONFIRMED >=20 >=20 > SCTP Endpoint behavior > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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. How can that happen? > - 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. >=20 > 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. >=20 > 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. =20 >=20 > 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. >=20 > Use Cases: >=20 > 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. Again. This requires the application to create a new end-point and = re-try to establish a new association using the new local end-point. How can the application = how that the problem is a local port number collision and no the peer being currently = unreachable? > 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. The can be congestion on the patch between the SCTP end-points, I agree. = But in case of a packet drop due to congestion or any other reason for packet drop, = retransmitting the packet is a way to handle it. In case of a local port number collision, = retransmission is not a way to handle this. How can the sender distinguish these two scenarios? >=20 > 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. See above. > INIT-ACK packet contains a new option that indicates the list of IP = addresses is NOT CONFIRMED I don't understand this. Whether addresses are confirmed or not are a = local issue on the sender side, not something the peer specifies. If a peer using a private = address talks to a peer with public addresses, but can locally decided to run send HBs to ensure NAT = binding table entries are generated. No need to let this being controlled by the peer. The = peer does not know if it is talking to nodes behind a NAT or not. >=20 > Since the set of remote IP addresses is not CONFIRMED, client will = start probing with HB. This can just be a local decision. >=20 > 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 Why would this be send? > - 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". >=20 > 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. >=20 >=20 > 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. See above. > 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. >=20 > When succeeding, since the set of remote IP addresses is not = CONFIRMED, client and server will > start probing with HB. I do see that the client can put entries into the NAT binding table by = sending HB to the public addresses of the peer. But I don't see how the server does know the = public addresses or the client. The client can not put its private addresses into the INIT chunk due to = scoping rules. So even though the client is multihomed, the peer doesn't know this. >=20 > The behavior of the peers is the same as described above in case 2. >=20 > Same as case 2, multihomed Associations may not be completed. >=20 > 4. Multihomed vs multihomed (public IP addresses unknown to the = multihomed peer) Just to be clear: In my view each node only knows its own addresses. = These can be public or private IP addresses (let us not consider link local addresses). So in 1., 2., = and 3., the server has public IP addresses it knows. The client has private IP-addresses it = knows, but not its public addresses seem by it peer. > This case begins as the single-homed vs single-homed case until the = Association is established. >=20 > 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 =3D 0.0.0.0 using > one of the internal IP address as source towards a CONFIRMED peer's IP = address. That requires cross routing to be working. This might or might not work. = It also requires specific handling at the sender (it must be able to control the outgoing = interface). >=20 > 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". I don't understand the vtag mismatch cases. How can they occur? >=20 > Same as case 2, multihomed Associations may not be completed. >=20 > 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. >=20 > 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. This mean that the single packet loss due to a temporary failure will = result in a permanent failure. >=20 > 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. >=20 > 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 Isn't his a form of a local port number collision? You say it is very = rare. Just to be sure, you agree the the birthday paradoxon considerations apply here. > mechanism that doesn't provide full capacity. A multihomed = configuration can help reducing the > blocking probability. >=20 > 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. >=20 > 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. I think whatever is written in an RFC would need to give parameters to = be used in the Internet. Parameters to be used in specific application scenarios (signalling = networks for nG (n=3D3,4,5,...)) are not considered in these documents (I agree, that this is bad, but = that is a different story). However, it should be OK to give a timer value for the NAT timer used in = the public Internet and put that in relation to the HB timer. I guess that is the only timer = relevant for keeping the entries in the NAT binding table active. >=20 > 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. There is no value for NATTimer which fulfils this constraint. I guess = there is a typo? >=20 >=20 > 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=3D0 cannot be used, the NAT device need to parse the received = INIT chunk and retrieve the > Initiate Tag that will be used as VTAG. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > Ericsson=20 >=20 > Claudio Porfiri > System Developer >=20 > Developer > BNEW DNEW NSV PPA RAN Infra Architecture > Mobile: +46761498209 > claudio.porfiri@ericsson.com >=20 >=20 > Ericsson > Isafjordsgatan 14E > 164 80,Stockholm > Sweden >=20 > 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 =20 > This communication is confidential. Our email terms > www.ericsson.com/en/legal/privacy/email-disclaimer=20