Endpoint independent mapping is default behaviour Matus
From: John Biscevic <john.bisce...@bahnhof.net> Sent: Tuesday, December 18, 2018 10:03 AM To: Ole Troan <otr...@employees.org>; Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) <matfa...@cisco.com> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping Hi Matus, There must be some misunderstanding! We're discussing endpoint INdependent mapping which as far as I know isn't currently present in VPP. The issue being that the current NAT implementations break certain services as clients end up with different external IPs in various situations where an endpoint service might use a different IP and port but still expect the same IP, or where the desired external IP and port can't be reused since another session has occupied them because they're not reserved for the client. Sincerely, John Sent from my phone On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)" <matfa...@cisco.com<mailto:matfa...@cisco.com>> wrote: Hi, Endpoint-dependent NAT is not default behaviour, when you want to use endpoint-dependent NAT you need to adjust startup config https://wiki.fd.io/view/VPP/NAT#NAT44 Matus -----Original Message----- From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> On Behalf Of JB Sent: Tuesday, December 18, 2018 12:02 AM To: Ole Troan Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping Hi Ole, Absolutely, Endpoint independent mapping is the safest bet, which is why it is recommended. It is unfortunate that we cannot rely on services being IP source agnostic or that STUN will be used. Thus, even though Endpoint independent mapping can be considered non-efficient in its address and port allocation, we should perhaps consider it being the default implementation as the other implementation would be circumstantial and would benefit specific NAT deployments rather than require them, or else we run the risk of seeing broken services during NAT, especially on larger deployments. That way, exactly as you say, we could do endpoint dependent address and port mapping for the applications we know are safe, but would come second in priority. Interestingly enough, there's a scenario where we run into the danger of being unable to enact a proper remapping according to Endpoint independent mapping if all we do is track source IP and source port to the same external IP and external port from a pool, which is that unless those are reserved for the source IP and source port, in any larger deployment, another source IP might occupy it before we get a chance to. RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: https://tools.ietf.org/html/rfc4787 Also, RFC6888 does reflect its implementation for CGN, in which Endpoint independent mapping is almost necessary, unless deterministic NAT (potentially highly wasteful though) is used, as in the case where we use deterministic NAT it requires the provider to be strict on their internal allocation of RFC6598 (CGNAT) address space otherwise they'll have to allocate large networks that would be mostly unused, and very wasteful computationally when traversing the NAT allocations. Kind regards, John ________________________________________ From: Ole Troan Sent: Monday, December 17, 2018 10:26 PM To: John Biscevic Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping > This might be best answered by Matus since it regards NAT, but I'll throw it > out there for the whole group. > > The endpoint-dependent feature of the NAT plugin - Endpoint address AND port > dependent I presume from the 6-tuple description of it - allows us to map the > same internal source IP and port to the same external IP when targeting a > certain past destination IP AND port, correct? > My concern is more of the situations where services initially create a > connection to one endpoint address, and then create another session to > another endpoint address, expecting the same source address to match the > client. > > Client opens a connection to endpoint X using external IP A, which proceeds > to instruct client to open a session to endpoint Y, both endpoints share the > same backend and expect the client to have IP A but since it's a new session > and we're doing dynamic NAT, the client ends up with external IP B, breaking > the chain. Many services depend on this. > > The idea is that when a new NAT source IP is seen, that we reserve a certain > number of internal ports for that IP to the same number of external ports on > a single IP, so all connections originating from that NAT source IP will > always have the same external IP, thus allowing for endpoint services to not > lose track of client due to IP mismatch, which breaks service. Yes, and this is the reason why the IETF recommendeds against it, and recommends the use of endpoint independent mapping. In one sense, us at your peril, in the other sense, given that we've run out of Ipv4 addresses, that will have consequences for applications too. Address and port dependent mapping obviously has the great benefit of using the address/port space efficiently. One option we discussed, which I'm happy to encourage patches for, is to make the NAT mode, NAT traversal aware. E.g. it detects a STUN packet and makes that connection have endpoint independent mapping (for some time period). Inverse we could only do address and port dependent mappings for "applications" (aka UDP/TCP ports) we knew were safe. Opinions welcome! Cheers, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11662): https://lists.fd.io/g/vpp-dev/message/11662 Mute This Topic: https://lists.fd.io/mt/28785710/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
