NAT support #4630
Comments
|
Comment regarding the design: I'm in favor of using STUN. Any idea how we would carry STUN messages to the router and tell them appart from regular traffic? STUN, per the RFC, is described as UDP or TCP payload, with its own port. In our case we want it to go directly to the router's port. So we can't really carry it via underlay UDP; shall we carry it over UDP/SCION instead (may be with a router alert flag)? |
We currently have student looking into this in form of a Bachelor thesis, so it may make sense to wait for his results. I wouldn't know how to distinguish traffic if it were STUN traffic. That is one reason why I would prefer a custom solution, e.g. an extension to SCMP or something else. A custom protocol should also be very easy to implement. If performance is a concern, we are already inspecting packets in the border router (BR), so I think it should have little impact...? @jiceatscion Why do you prefer STUN? Because it is a known/existing protocol? Or because of performance concerns? @marcfrei Any comments? |
I'd basically +1 @tzaeschke's points regarding STUN vs. "a custom solution, e.g. an extension to SCMP or something else". |
|
My only reason was indeed because it is an already specified protocol, with ready-to-use libraries: not much new code to write, maintain and test, and no new specification to add to the ietf drafts. The fact that we can't rely on a dedicated UDP port might make that a no-go, I agree. |
|
We have discussed this at Anapaya and our preferred approach would be to have IP/UDP/STUN instead of IP/UDP/SCION/UDP/STUN for this. The reason is that the problem we are solving here is not NAT detection for SCION, but for the SCION underlay. I would reserve IP/UDP/SCION/UDP/STUN for when we eventually need STUN to detect SCION NATs (I hope that day never comes...). The router would need to distinguish between STUN and SCION packets, since they would be received on the same UDP port, however, STUN's magic cookie is there for exactly that purpose. |
|
@shitz Just to clarify:
Just a thought: if we go the IP?UDP?STUN route, would it be a good idea to still reserve the |
|
+1 for IP/UDP/SCION/STUN (I had completely overlooked that option). The router already has all the plumbing ready for it since that's how we carry BFD. |
Ok I see, but I don't really agree with that. It's also not IP/STUN instead there are well-known UDP or TCP ports for STUN. Why would we do something different for SCION/STUN? I expect this would raise flag during an eventual standardization.
It's not that the SCION NATs would need to discover their external address, but a SCION endhost BEHIND a SCION NAT - and exactly for this I suggest we use SCION/UDP/STUN, because that's then conceptually at the right layer.
How do you then distinguish between the two usecases? There might be a need for STUN for NATing that happens on the IP/UDP underlay and there might be a need for STUN for NATing that happens on the SCION/L4 level (SCION NAT). I argue we should address the former with IP/UDP/STUN since the NATing is on the IP/UDP underlay layer and the latter with SCION/UDP/STUN since the NATing is on the SCION layer.
As argued above, I wouldn't put STUN directly after the SCION header to be inline with how STUN for IP/UDP works. |
|
In the SCION open source telecon (2024-11-19) we agreed to pursue the IP/UDP/STUN approach.
Correction: We will provide the following PRs:
To clarify some of my previous points
The proposal says we would use the normal border router port, not a well-known port. This is done because apparently some NATs create separate mappings for separate port. Also, as @jiceatscion pointed out, we already have BFD over SCION, I think this is similar, but I don't know why it was decided that way.
I actually meant for the IP/UDP/STUN case that you proposed. The border router could just look at the byte where the |
|
For the record, given there is a method of robust demultiplexing, I'm sold on the IP/UDP/STUN. It's a detail, but, just to make sure I understand... nexthdr is the fifth byte of the scion hdr. The magic cookie starts at the fifth byte of the STUN hdr, so nexthdr coincides with the first byte of the magic cookie, does it not? Also neither the first nor the second byte of the magic cookie is 66: the cookie is described as being 0x2112A442 in network byte order. Am I confused? |
|
I know it's easy to get mixed-up, but network byte order is Big-endian; it puts the most significant byte first. That'd be 0x21, would it not? |
|
I think that's right. We need to look at 0x21 = 33 in decimal. At IANA, this is assigned to "Datagram Congestion Control Protocol". |
|
@jiceatscion @FR4NK-W @marcfrei @lukedirtwalker @shitz Unfortunately we forgot to mention one possibly important aspect of NAT detection over SCION vs IP/UDP/STUN: authentication. TL;DR: Implementing authentication in STUN may be quite difficult, using SCION and DRKey may be much easier. Options:
There are some things to consider:
Before we go ahead and submit and PRs, can I ask everybody to indicate whether this would pose a reason to change their mind to use SCION underneath our NAT traversal protocol? |
|
Sorry for the delay. I will get back to you when I had time to actually
think about it.
…On Mon, Nov 25, 2024 at 1:55 PM Tilmann ***@***.***> wrote:
@jiceatscion <https://github.com/jiceatscion> @FR4NK-W
<https://github.com/FR4NK-W> @marcfrei <https://github.com/marcfrei>
@lukedirtwalker <https://github.com/lukedirtwalker> @shitz
<https://github.com/shitz>
Unfortunately we forgot to mention one possibly important aspect of NAT
detection over SCION vs IP/UDP/STUN: *authentication*.
TL;DR:
*Implementing authentication in STUN may be quite difficult, using SCION
and DRKey may be much easier. However, it is not clear useful
authentication really is in this case.*
Options:
- Authentication in STUN requires a username/password combination. I
don't know how these are usually acquired, but it may be annoying/difficult
to get them inside the PAN layer to perform STUN authentication such that
it is transparent to the user and the application layer.
- If we were using SCION underneath, we could probably easily use
DRKey authentication for STUN. It would have to be modified and I would
avoid calling it STUN to avoid confusion.
There are some things to consider:
- I have the impression that STUN authentication is currently not
widely implemented, does anyone have a similar or contrary impression or
data points?
- I am not sure how much authentication adds to security. STUN packets
already have a nonce (TxID) for requests responses, so I think only a MitM
attacker could exploit this.
- DRKey has not been designed for NAT, but it should *probably* work
for this case. It would result in all hosts behind the NAT to be assigned
the same DRKey. This is of course not ideal but *should* work fine for
authenticating packets from the border router.
Before we go ahead and submit and PRs, can I ask everybody to indicate
whether this would pose a reason to change their mind to use SCION
underneath our NAT traversal protocol?
—
Reply to this email directly, view it on GitHub
<#4630 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BBLEYOBRKICJM7BF6GYFNWT2CMM27AVCNFSM6AAAAABOVZMSHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBYHAZDQMJUGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
JEAN-CHRISTOPHE HUGLY
Software Engineer
+41 79 455 68 69
***@***.*** ***@***.***>
scion.org <http://www.scion.org/>
SCION Association <https://www.linkedin.com/company/scion-association/>
<https://www.scion.org/>
|
|
I don't see where/why we would need auth TBH. AFAIU from reading a bit on the internet it seems that if you also do TURN in combination with STUN, then authentication would be important, but given we don't do that, we don't need it. |
As discussed in #4560 and in this proposal, we should implement NAT support.
Implementation is currently supervised by @marcfrei and @tzaeschke.
The text was updated successfully, but these errors were encountered: