[SAFE] IKE/IPsec with STUN Control

> As far as I understand, STUN in general, and STUN in 
> particular, can be used for any UDP-based always-on protocol. 
> ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such 
> as MIDI-over-RTP(?) or RTSP-based streaming), proprietary 
> UDP overlays (not giving any names)...

I looked at how IKE learns of an on-path NAT, and unfortunately
the IP addresses are hashed in the IKE exchange.  This prevents
the IKE endpoint from learning the IP address seen by its IKE
peer, and thus prevents the IKE endpoint from learning its own
public IP address.  To use STUN Control, you need to learn that
public IP address.  I see two approaches:

* It is possible to multiplex STUN, IKE, and IPsec ESP on the
same UDP port.  IKE-over-UDP starts with 4 bytes of zeros,
IPsec ESP starts with the 32-bit SPI, and STUN has known bits
in its header (first 16 bits indicate a STUN Request, Response,
or Indication, and has a fixed magic cookie in bits 32-64) and
the STUN SHA-1 fingerprint attribute.  While not ideal, it
would be possible for the IKE peers to demultiplex STUN on
that same UDP port so that they could learn the IP address
as seen by the other peer and use STUN Control to adjust their
timings.  

* Alternatively, the IKE peer (VPN concentrator) could
run a normal STUN server on the STUN port (UDP/3478) if we make
the (reasonable) assumption that the same NATs would be be
traversed for traffic to UDP/500, UDP/4500, and UDP/3478.  This
wouldn't require changes to VPN concentrator code.

I would lean towards the second approach.

-d

> And then, there is the relation to ICE in finding 
> "intermediary" NAT mappings in nested NATs scenarios.
> 
> At the same time, I thought SIP Outbound was going to 
> recommend TCP, so that 
> it could end up being a less likely "customer" of STUN control??
> 
> -- 
> Rémi Denis-Courmont
> 

_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe