search

scionproto / scion

SCION Internet Architecture
https://scion.org
Apache License 2.0
401 stars 161 forks source link

NAT support #4630

Open tzaeschke opened 2 months ago

tzaeschke commented 2 months ago

As discussed in https://github.com/scionproto/scion/pull/4560 and in this proposal, we should implement NAT support.

Implementation is currently supervised by @marcfrei and @tzaeschke.

jiceatscion commented 2 months ago

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)?

tzaeschke commented 2 months ago

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?

marcfrei commented 2 months ago

Any comments?

I'd basically +1 @tzaeschke's points regarding STUN vs. "a custom solution, e.g. an extension to SCMP or something else".

jiceatscion commented 2 months ago

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.

shitz commented 1 week ago

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.

tzaeschke commented 1 week ago

@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 NextHdr id for STUN (as determined by the magic number) just to allow even faster detection (and without going the validation error route) of STUN packets?

jiceatscion commented 1 week ago

+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.

shitz commented 1 week ago

The plan was to do IP/UDP/SCION/STUN (no UDP between SCION and STUN), not IP/UDP/SCION/UDP/STUN. This would allows us to use the SCION NextHdr field to quickly identify STUN packets without having to parse the UDP payload.

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.

I am not sure about SCION NATs, I would assume they know their external address and don't need to ask for it. Even if they do, the IP/UDP/SCION/STUN proposal should work for them (why not?).

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.

Also, for SCION NATs, if we think we need an additional STUN solution, wouldn't it be good to design now a single solution that works for all cases, instead of ending up with two separate STUN solution?

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.

Just a thought: if we go the IP?UDP?STUN route, would it be a good idea to still reserve the NextHdr id for STUN (as determined by the magic number) just to allow even faster detection (and without going the validation error route) of STUN packets?

As argued above, I wouldn't put STUN directly after the SCION header to be inline with how STUN for IP/UDP works.

tzaeschke commented 1 week ago

In the SCION open source telecon (2024-11-19) we agreed to pursue the IP/UDP/STUN approach.

We will provide a PR for the design doc, a separate PR for the implementation (PAN library) and potentially a 3rd PR for snet.

Correction:

We will provide the following PRs:

To clarify some of my previous points

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?

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.

Just a thought: if we go the IP?UDP?STUN route, would it be a good idea to still reserve the NextHdr id for STUN (as determined by the magic number) just to allow even faster detection (and without going the validation error route) of STUN packets?

As argued above, I wouldn't put STUN directly after the SCION header to be inline with how STUN for IP/UDP works.

I actually meant for the IP/UDP/STUN case that you proposed. The border router could just look at the byte where the NextHdr is and immediately tell if this is a STUN packet (without SCION header) if it has the byte equals 66, which is the byte value there that is imposed by the magic number (2nd byte of the magic number).

jiceatscion commented 1 week ago

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?

jiceatscion commented 1 week ago

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?

marcfrei commented 1 week ago

I think that's right. We need to look at 0x21 = 33 in decimal. At IANA, this is assigned to "Datagram Congestion Control Protocol".

tzaeschke commented 6 days ago

@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. However, it is not clear useful authentication really is in this case.

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?

jiceatscion commented 1 day ago

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 https://github.com/scionproto/scion/issues/4630#issuecomment-2488828140, 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/