From 2755a60bbfe9e300abbebd9051d951345a2a2435 Mon Sep 17 00:00:00 2001 From: Jan Luan Date: Mon, 23 Dec 2024 19:02:37 +0100 Subject: [PATCH] update design document --- doc/dev/design/NAT-address-discovery.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/doc/dev/design/NAT-address-discovery.rst b/doc/dev/design/NAT-address-discovery.rst index b49edf0f74..aad3eb39be 100644 --- a/doc/dev/design/NAT-address-discovery.rst +++ b/doc/dev/design/NAT-address-discovery.rst @@ -3,7 +3,7 @@ NAT IP/port discovery ********************* - Author(s): Marc Frei, Jan Luan, Tilmann Zäschke -- Last updated: 2024-12-11 +- Last updated: 2024-12-22 - Status: **WIP** - Discussion at: :issue:`4517` @@ -65,8 +65,12 @@ To avoid potential misunderstandings: this proposal only addresses the problem o the goal to also support NAT traversal techniques such as NAT hole punching SCION-based servers and peer-to-peer scenarios. -Also note that the NAT issue only exists for traffic between separate ASes. If both the client and the server are located within -the same AS, the server can simply send returning packets to the underlay source address of the client (which is visible to the server in this case). +Furthermore, the proposed solution involving border routers is only necessary for traffic between separate ASes. +For intra-AS traffic, the NAT problem can be solved by changing the endhost implentation such that returning packets are always sent back to the +underlay source address (which may be a NAT'ed) instead of the SCION source address. +This is possible since within the local AS, the underlay headers do not change during transit as opposed to the inter-AS case. +We note that this only works for servers listening on ports that are not routed through a SHIM dispatcher. +However, we hope that by the time our solution rolls out, SHIM dispatchers would have become obsolete. The implementation on the protocol level could be done in several ways: @@ -234,15 +238,14 @@ Implementation Necessary border router and snet library modifications have been coded for three approaches proposed in the *Proposal* section: STUN/UDP/IP, STUN/SCION/UDP/IP, and SCMP message extension. It was agreed that a PR would be created for the STUN/UDP/IP variant. -The STUN specification used is the newer specification (RFC5389). +The STUN specification used is the newer specification (`RFC 5389 `_). Support in client libraries (PAN, JPAN) will be added subsequently. Client Side Considerations -------------------------- - AS local traffic: For communication within the same AS, the endhost should send returning packets to the underlay source address of the sender - simply by reversing src/dst addresses of the underlay in addition to reversing the src/dst addresses in the SCION header. - The sending endhost would then not need to use STUN. + instead of the SCION source address. The sending endhost would then not need to use STUN. Rationale: Since AS local communication does not involve a border router, it would be unclear which border router the client should choose, if it were to send a STUN request. The AS may be split into multiple subnets, with different border routers in each subnet.