Wireguard setup with SIP

[Rick van Rein <rick@openfortress.nl>]

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 media-types@iana.org
   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.