* Re: DMVPM appreciation
2016-12-03 18:07 ` DMVPM appreciation John Huttley
@ 2016-12-03 18:48 ` Dave Taht
2016-12-04 3:01 ` Kalin KOZHUHAROV
2016-12-04 5:57 ` John Huttley
2 siblings, 0 replies; 5+ messages in thread
From: Dave Taht @ 2016-12-03 18:48 UTC (permalink / raw)
To: John Huttley; +Cc: WireGuard mailing list
I agree that wireguard is potentially a good substrate for what you
describe. There are messy details.
My personal goal is to also get it to do good congestion control
(adding fq_codel) next year while thinking hard about the problems
that tor had in that department.
On Sat, Dec 3, 2016 at 10:07 AM, John Huttley <john@mib-infotech.co.nz> wro=
te:
>
> When Wireguard was first announced, there were several comments like
> "Can you do DMVPM?"
>
> So
> What is DMVPN?
> Do we care?
> Can we do it better?
>
> DMVPN
> http://www.cisco.com/c/en/us/products/security/dynamic-multipoint-vpn-dmv=
pn/index.html
> Is a Cisco product to lets spokes create spoke-to-spoke links in an
> otherwise spoke-hub VPN architecture.
> If we have A<-> HUB <-> B then we can get A <-> B directly. This
> unloads the hub.
>
> So how do they do it?
> They document 3 things
> 1) mGRE tunnels.
> The tunnel is good old GRE on proto 47.
> For every endpoint you create an interface. So hub with 1000 spokes has
> int gre0 -> int gre999.
> Nope, not that dumb. They have a multipoint GRE, mGRE with one interface
> that can terminate all the tunnels.
> --Just like Wireguard.
>
> 2)Ipsec. But GRE is encapsulation only, so they protect it with ipsec.
> Presumably ESP transport mode.
> Wireguard doesn't need that.
>
>
> 3)NHRP. https://en.wikipedia.org/wiki/Next_Hop_Resolution_Protocol
> This is a repurposed bit of the ATM suite. Sort of DB of remote internet
> addresses (endpoints) that spokes look up to set up tunnels.
> Wireguard. So much easier.
>
> There is a 4th part. The actually doing it and the policy for
> controlling it.
>
> When you look at it, a spoke-hub network that can overlay itself is a
> mesh network.
> So, do we care about DMVPN? No, it's vendor specific.
>
> Can we do it better? Sure, Jason has already done all the hard work.
>
> The key thought going forward is that that security doesn't matter. It's
> outside the scope.
> If A,B,C are /already/ in the VPN, they are /already/ authorised.
> A tunnel overlay does not impact /security/, it impacts /routing/.
>
> I suggest looking up
> Homenet https://www.irif.fr/~jch/software/homenet/howto.html
>
> So lets consider a simplified case
> A <-> B <-> C
>
> A is sending a lot of data to C.
>
> Policy triggers starting a direct A <-> C tunnel.
>
> We need public key and endpoint to set up a tunnel.
>
> First. A can talk to C just fine on the VPN. Thats all the
> authentication required.
> A and C swap public keys
> Endpoints? you could look up myip.com, but there is one perfect way.
> A asks B, because if two nodes are peered, they always know the
> endpoint of their peer.
> In this case B knows how to contact A.
> B passes that back to A
> A then passes that to C along with A's public key
>
>
> Ok, UDP Rendevous and we have a A <-> C tunnel, no NHRP required.
> The routing daemon engages and a new route becomes active.
>
> --Dad
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DMVPM appreciation
2016-12-03 18:07 ` DMVPM appreciation John Huttley
2016-12-03 18:48 ` Dave Taht
@ 2016-12-04 3:01 ` Kalin KOZHUHAROV
2016-12-04 5:57 ` John Huttley
2 siblings, 0 replies; 5+ messages in thread
From: Kalin KOZHUHAROV @ 2016-12-04 3:01 UTC (permalink / raw)
To: John Huttley; +Cc: WireGuard mailing list
Hmm...
Really good high level theory ...
On Sun, Dec 4, 2016 at 3:07 AM, John Huttley <john@mib-infotech.co.nz> wrote:
> So lets consider a simplified case
> A <-> B <-> C
>
> A is sending a lot of data to C.
>
> Policy triggers starting a direct A <-> C tunnel.
>
> We need public key and endpoint to set up a tunnel.
>
Don't forget we need two more things:
* A --> C (over UDP)
* C --> A (over UDP)
Throw a few weird NAT/PAT and other ACLs in between and try again.
> First. A can talk to C just fine on the VPN. Thats all the
> authentication required.
>
Yes, but in the background A only talks to B over UDP... and B to C over UDP.
> A and C swap public keys
> Endpoints? you could look up myip.com, but there is one perfect way.
> A asks B, because if two nodes are peered, they always know the
> endpoint of their peer.
> In this case B knows how to contact A.
> B passes that back to A
> A then passes that to C along with A's public key
>
>
> Ok, UDP Rendevous and we have a A <-> C tunnel, no NHRP required.
> The routing daemon engages and a new route becomes active.
>
I think there may be cases where such situation is possible and highly
desirable.
The logic being, try to talk directly (using the protocol described
above), if it doesn't work, continue talking via B.
Reminds me of STUN and friends.
And an alternative will be centralized database/service advertising
public keys and endpoints (think PGP keyserver).
And then comes the WoT and then... Jason will shoot us for bringing
the complexity he is so fond of avoiding (and I am supporting him) :-D
Since this functionality can be implemented outside of Wireguard, as a
simple script (I guess 5 lines of Bash, but will leave the challenge
open), it is all a matter of convenience.
Nothing can be gained by "building it in", may be except tiny convenience.
If you try to script it, then provide clean documentation/test cases,
I am sure it can be included in
https://git.zx2c4.com/WireGuard/plain/contrib/examples/
Also consider the trust model you are changing, because security DOES matter :-)
As an example, think buying on Amazon from 3rd party, vs. talking to
them directly:
(1st -> 2nd case may be possible, 2nd ->1st is highly improbable)
* 1st case is more secure, but more expensive
* 1st provides a way to find your party, plus it provides some
mediatior/trust relationship (at cost)
* How often did you buy something via Amazon an then went directly to
the seller to buy more?
It is all about balancing security/cost and convenience of setup a
transaction, within some (implicit) trust/insurance model.
Cheers,
Kalin.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DMVPM appreciation
2016-12-03 18:07 ` DMVPM appreciation John Huttley
2016-12-03 18:48 ` Dave Taht
2016-12-04 3:01 ` Kalin KOZHUHAROV
@ 2016-12-04 5:57 ` John Huttley
2 siblings, 0 replies; 5+ messages in thread
From: John Huttley @ 2016-12-04 5:57 UTC (permalink / raw)
To: John Huttley; +Cc: WireGuard mailing list
Hmm...
Really good high level theory ...
> Don't forget we need two more things:
> * A --> C (over UDP)
> * C --> A (over UDP)
>Throw a few weird NAT/PAT and other ACLs in between and try again.
In one direction there is no need, because that's how we established the
tunnel. See below, we could make exposed endpoints a requirement.
>> First. A can talk to C just fine on the VPN. Thats all the
>> authentication required.
>>
>Yes, but in the background A only talks to B over UDP... and B to C
>over UDP.
Sorry I don't get what you mean. Anyone /could/ talk to anyone,
firewalls permitting.
>I think there may be cases where such situation is possible and highly
>desirable.
>The logic being, try to talk directly (using the protocol described
>above), if it doesn't work, continue talking via B.
>Reminds me of STUN and friends.
Actually we can simplify it further. Just make it a requirement of
overlaying that you have a valid listener. Then no UDP magic. Overly
works or it doesn't.
>And an alternative will be centralized database/service advertising
>public keys and endpoints (think PGP keyserver).
>And then comes the WoT and then... Jason will shoot us for bringing
>the complexity he is so fond of avoiding (and I am supporting him) :-D
Agreed. I don't think Jason will be more than mildly interested and it
shouldn't be a part of Wireguard itself.
>Since this functionality can be implemented outside of Wireguard, as a
>simple script (I guess 5 lines of Bash, but will leave the challenge
>open), it is all a matter of convenience.
>Nothing can be gained by "building it in", may be except tiny >convenience.
>If you try to script it, then provide clean documentation/test cases,
>I am sure it can be included in
>https://git.zx2c4.com/WireGuard/plain/contrib/examples/
Agreed.
>Also consider the trust model you are changing, because security DOES
>matter :-)
>As an example, think buying on Amazon from 3rd party, vs. talking to
>them directly:
>(1st -> 2nd case may be possible, 2nd ->1st is highly improbable)
If you are on the VPN, you are by definition, trusted as much as anyone is.
"Improbable" is a policy decision. Overlaying might not even be of
benefit. If C is on bad, slow connection, an overlay to C isn't going to
help. Policy needs to figure that out.
>* 1st case is more secure, but more expensive
>* 1st provides a way to find your party, plus it provides some
>mediatior/trust relationship (at cost)
>* How often did you buy something via Amazon an then went directly to
>the seller to buy more?
This isn't the use case I'm considering. I'm not quite sure what you mean.
>It is all about balancing security/cost and convenience of setup a
>transaction, within some (implicit) trust/insurance model.
Definitely don't know what you mean.
Regards
-Dad
^ permalink raw reply [flat|nested] 5+ messages in thread