search

scionproto / scion

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

NAT support #4630

Open tzaeschke opened 4 weeks ago

tzaeschke commented 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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.