Hello all, I would like to tell you about some work I'm doing to allow Wireguard sites to negotiate their setup over SIP. This can even be used to spontaneously setup VPNs with new parties, to the level that their SIP server is open to such requests.
The standard session setup and teardown is used, INVITE and BYE. Given the right SDP formulation, these can exchange the params for the tunnel; this is what I am sending in the current version, v=0 o=- 4124031101 285260646 IN IP6 2001:db8:666::666 s=- c=IN IP6 2001:db8:666::666 t=0 0 m=application 57660 udp vnd.wireguard a=fmtp:vnd.wireguard pubkey=YWl42m1t56sMAYKwGZUQZNuYG+AbdW9eE7KLj3KBT1M=;prefix=2001:db8:456:1::/64;pskmth=none a=sendrecv The traffic should be authenticated; for that I want to validate the From: and To: SIP headers using SASL, possibly with mutual authentication and possibly with key derivation (then set pskmth to a suitable value). I'm curious how you feel about this! In the SDP fragment above, I mentioned application/vnd.wireguard as a Media Type; these are best registered with IANA. In this application (and probably any other) this could represent the message flow as it is encapsulated into UDP. Would you agree on registering such a Media Type with IANA? I don't care who does it, but it would be the proper course of action. Code, SIP achieves Wireguard setup within localhost: https://gitlab.com/0cpm/subliminal/-/blob/master/src/wgsip.c Man page: https://gitlab.com/0cpm/subliminal/-/blob/master/doc/man/wgsip.1 SASL for SIP and HTTP: https://www.ietf.org/archive/id/draft-vanrein-sipauth-sasl-01.html https://www.ietf.org/archive/id/draft-vanrein-httpauth-sasl-07.html Context: The code arose as part of a project "Subliminal Messaging" that injects digital data into a POTS/VoIP call mixture. The idea is that phone calls would be *one* possible method for Wireguard setup, but the same idea would also work over Thanks, -Rick RFC 6838 says: The "application" top-level type is to be used for discrete data that do not fit under any of the other type names, and particularly for data to be processed by some type of application program. This is information that must be processed by an application before it is viewable or usable by a user. ... The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. ... Vendor-tree registrations will be distinguished by the leading facet "vnd.". That may be followed, at the discretion of the registrant, by either a media subtype name from a well-known producer (e.g., "vnd.mudpie") or by an IANA-approved designation of the producer's name that is followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures). While public exposure and review of media types to be registered in the vendor tree are not required, using the [email protected] mailing list for review is encouraged, to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval.
