From nobody Mon May 3 08:35:04 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 BA53A3A188E; Mon, 3 May 2021 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 UOsetgBLvt51; Mon, 3 May 2021 08:34:57 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDB53A1890; Mon, 3 May 2021 08:34:57 -0700 (PDT) Received: from smtpclient.apple (ip-109-41-65-75.web.vodafone.de [109.41.65.75]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 4D6B0721E2808; Mon, 3 May 2021 17:34:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Michael Tuexen In-Reply-To: Date: Mon, 3 May 2021 17:34:45 +0200 Cc: "draft-ietf-tsvwg-natsupp.all@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <45699343-71CC-4B63-B959-22E0313C6405@lurchi.franken.de> References: <03142829-58F8-4276-96DD-CCA0CF782737@lurchi.franken.de> To: Claudio Porfiri X-Mailer: Apple Mail (2.3654.80.0.2.43) 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: Mon, 03 May 2021 15:35:03 -0000 > On 27. Apr 2021, at 13:14, Claudio Porfiri = wrote: >=20 > Hi Michael, > thank you for the comments. > I think there are some points that I have missed and that need some = more work. > I am assuming that there are two families of SCTP users, the ones that = act and will always act as a > client where the concept of SCTP Endpoint is not so strong, for those = the source port number is not > really important as the user can use any; for those it should be = possible to specify a parameter > "ANY PORT" so that SCTP randomly selects a dynamic port as specified = by rfc6335. The second family > is tied to the SCTP Endpoint and shall use or be tied to well defined = port numbers when acting as > client or server. When using the socket API, where you can specify "ANY PORT" by using 0 = as the local port number, does mean that the transport layer selects a local port number once. = Once it is chosen, it isn't changed anymore. > When a SCTP user belongs to the first family, SCTP may try itself = different port numbers when > experiencing rtx timeout when sending INIT or the user can retry after = SCTP failure.=20 Yepp. An application would have to open a socket, try to to connect() = and after a timeout (which takes a long time) close the socket, create a new one and try again... = Basically, the application has to deal with local port number collisions and, in particular, has to = tolerate long delays. This is not required by the method described in the current ID. More comments in-line. Best regards Michael >=20 > On your comments, I have answered in-line. >=20 > Regards, > Claudio. >=20 > -----Original Message----- > From: Michael Tuexen =20 > Sent: Saturday, April 24, 2021 2:20 PM > To: Claudio Porfiri > Cc: draft-ietf-tsvwg-natsupp.all@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP >=20 >> 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, >=20 > 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. >=20 > Regarding your proposal, see my comments in-line. >=20 > 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. > [teiclap] Yes, port-forwarding is manually specifying entries in the = NAT binding table. OK, thanks for the clarification. This is also possible using the method = described in the ID. >=20 >>=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. > [teiclap] By introducing the possibility to choose a different source = port when INIT fails, I have > introduced a sort of NAPT with the difference that SCTP is in full = control of the port. I agree on > the point that SCTP Endpoint cannot change the port number as the port = number is part of the > Endpoint definition. It would be a better description that an SCTP = user can choose another SCTP > Endpoint, limited to the kind of user itself. Whether is SCTP = selecting alternative Endpoints or the > user to explicitly doing that or even SCTP supporting ephemeral = Endpoints is worth to talk about. OK. This means we agree on it. Local port number collisions in your = proposal require some action by the application. I think the additional delay is also critical... >=20 >> 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. > [teiclap] Agree. >=20 >>=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. > [teiclap] Correct. It does depend on SCTP, this part I need to = rewrite. >=20 >> 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? > [teiclap] Here I assumed that a port collision can be seen as = temporary or permanent network outage. I understand your view, but I disagree... >=20 >=20 >>=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. > [teiclap] This is a new scenario that I didn't consider. All the Load = Balancers I have seen so far > are integrated with a NAT, but having a LB that can redirect without = being NAT itself I have to > think and write a Use Case for it. Thanks. >=20 >>=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. > [teiclap] Correct, this is the integrated LB+NAT. I will fix it. >=20 >>=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 > = --------------------------------------------------------------------------= -------------------------- >> ----- >>=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. > [teiclap] I need to specify it better. One of the problem with SCTP = server behind NAT is that > there's no way for selecting which one if the same port is used. I = meant that when instantiating > SCTP Endpoints behind NAT, the port number assignment needs to be = planed for avoiding clients to be > connected to the wrong server.=20 >=20 >> - 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? > [teiclap] INIT chunk wil be retransmitted according to the Endpoint = rules. Since NAT will silently > discard those INIT, the Endpoint will experience expiring the = retransmission counter. But this takes a loooooong time... >=20 >> *** 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. > [teiclap] Correct. >=20 >> *** 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. > [teiclap] This is a corner case that may happen when the server is a = distributed Endpoint in > transversal network, so that there are different NATs on different = paths of a multihoming > association. If the Association is closed, the NAT tables will survive = in the different NATs for > different times. If a new association is established between the same = Endpoints and the Load > Balancer function selects a different SCTP Host, and still the path = towards the old SCTP Host exists > because the related NAT hasn't removed the NAT-table entry yet, it's = possible that packets are sent > to the old SCTP Host that will see them as OOTB.=20 Hmm. I assumed that a load balancer acts for incoming packets in a = deterministic fashion. >=20 >>=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? > [teiclap] Because it's an old entry belonging to an Association that = has been closed. Ahh, I see. >=20 >>=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? > [teiclap] Explained above, due to SCTP and NAT be asynchronous. >=20 >> - 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? > [teiclap] Correct. The whole part with Endpoints and port number = requires rewriting. >> 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? > [teiclap] The sender cannot distinguish. >=20 >>=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. > [teiclap] The reason behind NOT CONFIRMED is to reduce the check for = odd OOTB chunks to HB. I agree > that this part can be improved. >=20 >>=20 >> Since the set of remote IP addresses is not CONFIRMED, client will = start probing with HB. > This can just be a local decision. > [teiclap] Yes, this is a local decision. To be improved in the overall = description. >=20 >>=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? > [teiclap] Correct. This is possibly a mistake. I need to check again = the Use Case. >=20 >> - 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. > [teiclap] This assumes that it's possible to have a local = configuration in the SCTP Host where > public IP addresses are stored. It depends on implementation. I my view, an end-point only lists IP addresses it owns, not addresses = it thinks the peer might see them. It is very hard to know which addresses are observed by a = peer. >=20 >>=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. > [teiclap] I was not clear in the description. Retransmissions are kept = according to rfc4960. But then it takes a very long time to deal with local port number = collisions. >=20 >>=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. > [teiclap] Yes. >=20 >> 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). >=20 > 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? > [teiclap] Sure! It's 2 * HB timer < NATTimer < 4 * HB timer OK. I see. Sounds good. >=20 >>=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 >>=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 >=20