NAT support

[tzaeschke]

As discussed in #4560 and in this proposal, we should implement NAT support.

Implementation is currently supervised by @marcfrei and @tzaeschke.

[jiceatscion]

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]

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]

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]

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.