[WireGuard] Fwd: WireGuard cryptokey routing

[WireGuard] Fwd: WireGuard cryptokey routing

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

Hi Norm,

I'm moving this discussion over to the mailing list. Please be sure to keep
wireguard@lists.zx2c4.com CC'd in your replies if you'd like a response.

Our prior conversation follows below.

Regards,
Jason

Forwarded conversation
Subject: WireGuard cryptokey routing
------------------------

From: *Norman Shulman* <norman.shulman@n-dimension.com>
Date: Tue, Jul 5, 2016 at 5:58 PM
To: team@wireguard.io


You state:

"
In the server configuration, when the network interface wants to send a
packet to a peer (a client), it looks at that packet's destination IP and
compares it to each peer's list of allowed IPs to see which peer to send it
to.
...
In other words, when sending packets, the list of allowed IPs behaves as a
sort of routing table
"

But the allowed IPs can be non-routable addresses, so they are not
necessarily unique.

----------
From: *Jason A. Donenfeld* <Jason@zx2c4.com>
Date: Tue, Jul 5, 2016 at 6:09 PM
To: Norman Shulman <norman.shulman@n-dimension.com>


Hi Norman,

Can you expand what you mean a little bit by "not necessarily unique"?
And why that matters? I'm not sure I understand the thrust of your
point.

Thanks,
Jason

----------
From: *Norman Shulman* <norman.shulman@n-dimension.com>
Date: Tue, Jul 5, 2016 at 6:14 PM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>


Hi Jason,

Many clients use the non-routable 192.168.0.0/16 addresses. How can looking
up such an address identify the client?

Thanks.

Norm


----------
From: *Jason A. Donenfeld* <Jason@zx2c4.com>
Date: Tue, Jul 5, 2016 at 6:19 PM
To: Norman Shulman <norman.shulman@n-dimension.com>


Hi Norm,

I think you're misunderstanding how things work. I'll try to explain a
bit more clear here:

A linux system has several network interfaces, such as lo, eth0,
wlan0, wg0. The ordinary kernel routing table determines which
interface to use when sending outgoing packets. So, let's say the
kernel routing table is setup to route 192.168.0.0/16 via WireGuard:

# ip route add 192.168.0.0/16 dev wg0
or
# ip addr add 192.168.0.5/16 dev wg0

Now userspace can send packets that will be handled by the wireguard driver:

# ping 192.168.32.19
...

When that ping packet hits the wireguard driver, it has a dst IP of
192.168.32.19. What does wireguard do with it now?

It looks in the cryptokey routing table to see if 192.168.32.19
belongs to any peers. If so, it uses that peer's public key to make a
secure session and encrypt that ping packet. It then sends it off to
the peer's configured external internet endpoint.

Does this make more sense? Or is there still something you're wondering
about?

Regards,
Jason

----------
From: *Norman Shulman* <norman.shulman@n-dimension.com>
Date: Tue, Jul 5, 2016 at 6:23 PM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>


Hi Jason,

I'm still wondering what wireguard does if more than one peer has the
address 192.168.32.19.

Thanks.

Norm

----------
From: *Jason A. Donenfeld* <Jason@zx2c4.com>
Date: Tue, Jul 5, 2016 at 6:30 PM
To: Norman Shulman <norman.shulman@n-dimension.com>


Hi Norm,

If you run these commands:

wg set wg0 peer ABCD allowed-ips 192.168.32.19/32
wg set wg0 peer EFGH allowed-ips 192.168.32.19/32

After the first command ABCD has 192.168.32.19/32. After the second
command, ABCD has no allowed ips, and EFGH has 192.168.32.19/32.

However, if you run these commands:

wg set wg0 peer ABCD allowed-ips 192.168.32.0/24
wg set wg0 peer EFGH allowed-ips 192.168.32.19/32

After running both commands, ABCD will have 192.168.32.0/24 and EFGH
will have 192.168.32.19/32. However, when sending packets, the routing
table lookups will always match on the most specific match, so ABCD
will not be able to send or receive packets for 192.168.32.19/32.

Make sense?

Jason

[-- Attachment #2: Type: text/html, Size: 7234 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Norman Shulman]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Hi Jason,

Makes sense, but what if both clients have the same address (
192.168.32.19/32)?

Norm

On Tue, Jul 5, 2016 at 12:30 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> Hi Norm,
>
> If you run these commands:
>
> wg set wg0 peer ABCD allowed-ips 192.168.32.19/32
> wg set wg0 peer EFGH allowed-ips 192.168.32.19/32
>
> After the first command ABCD has 192.168.32.19/32. After the second
> command, ABCD has no allowed ips, and EFGH has 192.168.32.19/32.
>
> However, if you run these commands:
>
> wg set wg0 peer ABCD allowed-ips 192.168.32.0/24
> wg set wg0 peer EFGH allowed-ips 192.168.32.19/32
>
> After running both commands, ABCD will have 192.168.32.0/24 and EFGH
> will have 192.168.32.19/32. However, when sending packets, the routing
> table lookups will always match on the most specific match, so ABCD
> will not be able to send or receive packets for 192.168.32.19/32.
>
> Make sense?
>
> Jason
>



-- 
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada

Tel: 905 707-8884 x 226
Fax: 905 707-0886

This email and any files transmitted with it are solely intended for the
use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error, please
immediately notify the sender and delete this message in all its forms.

[-- Attachment #2: Type: text/html, Size: 2653 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Jason A. Donenfeld]

One peer may have multiple allowed-ips.

Several peers may not share the same IP.

Re: [WireGuard] WireGuard cryptokey routing

[Norman Shulman]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

How is this enforced? How does this scale?

On Tue, Jul 5, 2016 at 3:06 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> One peer may have multiple allowed-ips.
>
> Several peers may not share the same IP.
>



-- 
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada

Tel: 905 707-8884 x 226
Fax: 905 707-0886

This email and any files transmitted with it are solely intended for the
use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error, please
immediately notify the sender and delete this message in all its forms.

[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Jason A. Donenfeld]

On Tue, Jul 5, 2016 at 9:09 PM, Norman Shulman
<norman.shulman@n-dimension.com> wrote:
> How is this enforced?
Receiving, line 238 here:
https://git.zx2c4.com/WireGuard/tree/src/receive.c#n238
Sending, line 112 here:
https://git.zx2c4.com/WireGuard/tree/src/device.c#n112

> How does this scale?
The same way in which an ethernet network scales? One ethernet device
can have multiple IPs, but separate (unbonded) ethernet devices
generally do not share IPs.

Re: [WireGuard] WireGuard cryptokey routing

[Norman Shulman]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

Ethernet networks don't scale; that's why we have IP networks.

So in general a client needs one address for each server? Rather limiting
for clients on small subnets, especially considering the case of n clients
on a subnet, each connecting to m different servers.




On Tue, Jul 5, 2016 at 3:11 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> On Tue, Jul 5, 2016 at 9:09 PM, Norman Shulman
> <norman.shulman@n-dimension.com> wrote:
> > How is this enforced?
> Receiving, line 238 here:
> https://git.zx2c4.com/WireGuard/tree/src/receive.c#n238
> Sending, line 112 here:
> https://git.zx2c4.com/WireGuard/tree/src/device.c#n112
>
> > How does this scale?
> The same way in which an ethernet network scales? One ethernet device
> can have multiple IPs, but separate (unbonded) ethernet devices
> generally do not share IPs.
>



-- 
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada

Tel: 905 707-8884 x 226
Fax: 905 707-0886

This email and any files transmitted with it are solely intended for the
use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error, please
immediately notify the sender and delete this message in all its forms.

[-- Attachment #2: Type: text/html, Size: 2086 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Hey Norman,

I'm not sure I follow here. Could you maybe describe a concrete example of
what your concern is, with as much detail as possible?

Jason
On Jul 6, 2016 5:31 PM, "Norman Shulman" <norman.shulman@n-dimension.com>
wrote:

> Ethernet networks don't scale; that's why we have IP networks.
>
> So in general a client needs one address for each server? Rather limiting
> for clients on small subnets, especially considering the case of n clients
> on a subnet, each connecting to m different servers.
>
>
>
>
> On Tue, Jul 5, 2016 at 3:11 PM, Jason A. Donenfeld <Jason@zx2c4.com>
> wrote:
>
>> On Tue, Jul 5, 2016 at 9:09 PM, Norman Shulman
>> <norman.shulman@n-dimension.com> wrote:
>> > How is this enforced?
>> Receiving, line 238 here:
>> https://git.zx2c4.com/WireGuard/tree/src/receive.c#n238
>> Sending, line 112 here:
>> https://git.zx2c4.com/WireGuard/tree/src/device.c#n112
>>
>> > How does this scale?
>> The same way in which an ethernet network scales? One ethernet device
>> can have multiple IPs, but separate (unbonded) ethernet devices
>> generally do not share IPs.
>>
>
>
>
> --
> Norman Shulman
> Sr. Developer/Architect
> N-Dimension Solutions Inc.
> 9030 Leslie St, Unit 300
> Richmond Hill, ON L4B 1G2
> Canada
>
> Tel: 905 707-8884 x 226
> Fax: 905 707-0886
>
> This email and any files transmitted with it are solely intended for the
> use of the named recipient(s) and may contain information that is
> privileged and confidential. If you receive this email in error, please
> immediately notify the sender and delete this message in all its forms.
>

[-- Attachment #2: Type: text/html, Size: 2753 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

On Wed, Jul 06, 2016 at 11:31:28AM -0400, Norman Shulman wrote:
> Ethernet networks don't scale; that's why we have IP networks.

Wireguard does not use Ethernet at all, it operates purely at layer 3 (IP).

IP over Ethernet would use a reactive scheme (ARP, Neighbour Discovery) to
discover the mapping between IP addresses and link-layer addresses.  This
is part of the reason why Ethernet does not scale well.

Wireguard, on the other hand, does the equivalent mapping statically, via
the AllowedIPs directive.  The mapping is also slightly different:

- with Ethernet, you map from IP address to MAC address (using ARP or ND)

- Wireguard maps from IP address to public key (using AllowedIP, so this
  is completely static).  A public key is then mapped to the IP address
  and UDP port of the peer on the Internet, using the last known endpoint
  of the peer.  This makes this second mapping mostly dynamic, even though
  it falls back to a static "Endpoint" configuration for bootstrap.

Does that make things clearer for you?

> So in general a client needs one address for each server? Rather limiting
> for clients on small subnets, especially considering the case of n clients
> on a subnet, each connecting to m different servers.
> 
> 
> 
> 
> On Tue, Jul 5, 2016 at 3:11 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> > On Tue, Jul 5, 2016 at 9:09 PM, Norman Shulman
> > <norman.shulman@n-dimension.com> wrote:
> > > How is this enforced?
> > Receiving, line 238 here:
> > https://git.zx2c4.com/WireGuard/tree/src/receive.c#n238
> > Sending, line 112 here:
> > https://git.zx2c4.com/WireGuard/tree/src/device.c#n112
> >
> > > How does this scale?
> > The same way in which an ethernet network scales? One ethernet device
> > can have multiple IPs, but separate (unbonded) ethernet devices
> > generally do not share IPs.
> >

> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/wireguard


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Norman Shulman]

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]

Look at it from the server side. There are millions of clients on millions
of 192.168.1.0/24 networks, yet a server can communicate with no more than
254 of them.


On Wed, Jul 6, 2016 at 11:48 AM, Baptiste Jonglez <
baptiste@bitsofnetworks.org> wrote:

> On Wed, Jul 06, 2016 at 11:31:28AM -0400, Norman Shulman wrote:
> > Ethernet networks don't scale; that's why we have IP networks.
>
> Wireguard does not use Ethernet at all, it operates purely at layer 3 (IP).
>
> IP over Ethernet would use a reactive scheme (ARP, Neighbour Discovery) to
> discover the mapping between IP addresses and link-layer addresses.  This
> is part of the reason why Ethernet does not scale well.
>
> Wireguard, on the other hand, does the equivalent mapping statically, via
> the AllowedIPs directive.  The mapping is also slightly different:
>
> - with Ethernet, you map from IP address to MAC address (using ARP or ND)
>
> - Wireguard maps from IP address to public key (using AllowedIP, so this
>   is completely static).  A public key is then mapped to the IP address
>   and UDP port of the peer on the Internet, using the last known endpoint
>   of the peer.  This makes this second mapping mostly dynamic, even though
>   it falls back to a static "Endpoint" configuration for bootstrap.
>
> Does that make things clearer for you?
>
> > So in general a client needs one address for each server? Rather limiting
> > for clients on small subnets, especially considering the case of n
> clients
> > on a subnet, each connecting to m different servers.
> >
> >
> >
> >
> > On Tue, Jul 5, 2016 at 3:11 PM, Jason A. Donenfeld <Jason@zx2c4.com>
> wrote:
> >
> > > On Tue, Jul 5, 2016 at 9:09 PM, Norman Shulman
> > > <norman.shulman@n-dimension.com> wrote:
> > > > How is this enforced?
> > > Receiving, line 238 here:
> > > https://git.zx2c4.com/WireGuard/tree/src/receive.c#n238
> > > Sending, line 112 here:
> > > https://git.zx2c4.com/WireGuard/tree/src/device.c#n112
> > >
> > > > How does this scale?
> > > The same way in which an ethernet network scales? One ethernet device
> > > can have multiple IPs, but separate (unbonded) ethernet devices
> > > generally do not share IPs.
> > >
>
> > _______________________________________________
> > WireGuard mailing list
> > WireGuard@lists.zx2c4.com
> > http://lists.zx2c4.com/mailman/listinfo/wireguard
>
>


-- 
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada

Tel: 905 707-8884 x 226
Fax: 905 707-0886

This email and any files transmitted with it are solely intended for the
use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error, please
immediately notify the sender and delete this message in all its forms.

[-- Attachment #2: Type: text/html, Size: 4084 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Jason A. Donenfeld]

On Thu, Jul 7, 2016 at 6:15 PM, Norman Shulman
<norman.shulman@n-dimension.com> wrote:
> Look at it from the server side. There are millions of clients on millions
> of 192.168.1.0/24 networks, yet a server can communicate with no more than
> 254 of them.

Voila, this is where you are most certainly mistaken.

While a client might have 192.168.1.8 as their IP address for eth0,
their IP address for wg0 can be something completely different. Want a
million clients? Use a /20 as your wireguard device inner IP.

Anyway, why don't you tell us all what you actually want to do, rather
than these meandering theoretical questions? Then maybe we can help
you effectively.

Re: [WireGuard] WireGuard cryptokey routing

[Norman Shulman]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

Hi Jason,

Sorry if this sounds too theoretical. I'm just trying to understand the
cryptokey routing well enough to determine if it's suitable for our use.
The main problem I have is understanding how you can base routing on
non-routable addresses, which are not unique.

Thanks.

Norm


On Thu, Jul 7, 2016 at 12:18 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> On Thu, Jul 7, 2016 at 6:15 PM, Norman Shulman
> <norman.shulman@n-dimension.com> wrote:
> > Look at it from the server side. There are millions of clients on
> millions
> > of 192.168.1.0/24 networks, yet a server can communicate with no more
> than
> > 254 of them.
>
> Voila, this is where you are most certainly mistaken.
>
> While a client might have 192.168.1.8 as their IP address for eth0,
> their IP address for wg0 can be something completely different. Want a
> million clients? Use a /20 as your wireguard device inner IP.
>
> Anyway, why don't you tell us all what you actually want to do, rather
> than these meandering theoretical questions? Then maybe we can help
> you effectively.
>



-- 
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada

Tel: 905 707-8884 x 226
Fax: 905 707-0886

This email and any files transmitted with it are solely intended for the
use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error, please
immediately notify the sender and delete this message in all its forms.

[-- Attachment #2: Type: text/html, Size: 2245 bytes --]

Re: [WireGuard] WireGuard cryptokey routing

[Jason A. Donenfeld]

On Thu, Jul 14, 2016 at 11:16 PM, Norman Shulman
<norman.shulman@n-dimension.com> wrote:
> Sorry if this sounds too theoretical. I'm just trying to understand the
> cryptokey routing well enough to determine if it's suitable for our use. The
> main problem I have is understanding how you can base routing on
> non-routable addresses, which are not unique.

I don't think it's productive for either of us for me to continue
answering questions posed in this form. How about instead you write
down an example network layout ("Subnet A is 10.2.3.0/24, Subnet B
is...") and then present a problem you'd like to solve with WireGuard
but are having trouble figuring out how.