From: Rick van Rein <email@example.com>
Subject: Wireguard setup with SIP
Date: Wed, 19 Oct 2022 09:29:54 +0000 [thread overview]
Message-ID: <20221019092954.GA22238@openfortress.nl> (raw)
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,
o=- 4124031101 285260646 IN IP6 2001:db8:666::666
c=IN IP6 2001:db8:666::666
m=application 57660 udp vnd.wireguard
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
Code, SIP achieves Wireguard setup within localhost:
SASL for SIP and HTTP:
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
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.,
While public exposure and review of media types to be registered in
the vendor tree are not required, using the firstname.lastname@example.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.
reply other threads:[~2022-10-24 14:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).