Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Baptiste Jonglez <baptiste@bitsofnetworks.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>,
	Jan De Landtsheer <jan@delandtsheer.eu>
Subject: Re: Multihomed server issue
Date: Fri, 11 Aug 2017 00:16:06 +0200	[thread overview]
Message-ID: <20170810221606.GC30478@lud> (raw)
In-Reply-To: <CAHmME9q5T-KpTatXxLZ_H_j_Ly=ZTX63wKTeYD=jqKQeupFFpQ@mail.gmail.com>

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

Hi Jason,

On Thu, Aug 10, 2017 at 04:29:54PM +0200, Jason A. Donenfeld wrote:
> 1. Packet from peer P arrives from src:A dst:B
> 2. WireGuard records that it should contact P at src:B dst:A
> 3. When sending an encrypted packet to P, it asks for which interface
> to use for src:B dst:A. The routing API returns interface I.
> 4. We ask whether interface I has an address B assigned to it. If yes,
> we transmit the packet as src:B dst:A using interface I, and return.
> If no, we move to step 5:
> 5. We ask which interface and src IP we should use for src:default
> dst:A. The routing API returns interface I' (which may be the same as
> I or perhaps not) and a default src address, B', for interface I'.
> 6. We transmit the packet as src:B' dst:A using interface I'.
> 
> In the past, this has been sufficient for handling issues with
> multihomed servers, while still dealing gracefully with IP address
> changes.
> 
> It seems like the problem you're facing is that B does not belong to
> I, because B belongs to an unrouted dummy0 interface. The solution
> would be to change the question of step 4 to instead ask if _any_
> interface contains B, not just the returned interface I. While this is
> essentially what's done for IPv6, I'm not certain this is the correct
> behavior for IPv4. Do you know of any relevant RFCs for your use of v4
> dummy interfaces and RTS routing? Or some other reference?

This is essentially a difference of weak vs. strong host model, see
https://tools.ietf.org/html/rfc1122#page-61

The RFC is quite clear:

    If the datagram is sent in response to a received datagram, the source
    address for the response SHOULD be the specific-destination address of
    the request.

However, a system with a strong host model would drop the incoming packets
in the first place, still from the RFC:

    A host MAY silently discard an incoming datagram whose destination
    address does not correspond to the physical interface through which it
    is received.

    A host MAY restrict itself to sending (non-source-routed) IP datagrams
    only through the physical interface that corresponds to the IP source
    address of the datagrams.

But Linux has adopted the weak host model, see for instance the documentation
for "arp_filter" and "arp_announce" in Documentation/networking/ip-sysctl.txt.

So I think your proposed change makes sense, you should use the
destination address of the request as source address, even if this address
is not assigned to the outgoing interface.

Baptiste

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

  parent reply	other threads:[~2017-08-10 21:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28  0:51 Wang Jian
2017-07-31 15:34 ` Jason A. Donenfeld
2017-08-01  2:01   ` Wang Jian
2017-08-01  3:06     ` Jason A. Donenfeld
2017-08-01 11:28       ` Wang Jian
2017-08-03  3:00         ` Wang Jian
2017-08-03 12:59           ` Jason A. Donenfeld
2017-08-03 18:38             ` Wang Jian
2017-08-10 14:29               ` Jason A. Donenfeld
2017-08-10 18:43                 ` Jason A. Donenfeld
2017-08-10 21:17                   ` Jan De Landtsheer
2017-08-10 22:16                 ` Baptiste Jonglez [this message]
2017-08-10 23:50                   ` Jason A. Donenfeld
2017-08-12  1:55                     ` Jason A. Donenfeld
2017-08-12 16:08                 ` Wang Jian
2017-09-07 21:28                   ` Jason A. Donenfeld
2017-09-09  8:26                     ` Wang Jian
2017-09-20 13:15                       ` Jason A. Donenfeld

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170810221606.GC30478@lud \
    --to=baptiste@bitsofnetworks.org \
    --cc=Jason@zx2c4.com \
    --cc=jan@delandtsheer.eu \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).