Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

Ole Troan <otroan@employees.org> Thu, 30 October 2014 07:29 UTC

Return-Path: <otroan@employees.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100131AD029; Thu, 30 Oct 2014 00:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbRK3OBWm19U; Thu, 30 Oct 2014 00:29:33 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7551AD036; Thu, 30 Oct 2014 00:29:33 -0700 (PDT)
Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 37F4F62C4; Thu, 30 Oct 2014 00:29:32 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <20141030003933.GS5186@eidolon>
Date: Thu, 30 Oct 2014 08:29:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC0B76ED-9D41-4945-A541-E7E3CDC00961@employees.org>
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net> <DFE4317C-E4B6-44AB-AED4-2FBBBD2888DA@cisco.com> <B445E8FD-13EE-4014-8D1C-7C9D4A188D2D@cisco.com> <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon> <B6D9E5BD-8903-4133-8947-BB8AEAD97AA4@cisco.com> <5450D7ED.9010806@globis.net> <C9754B86-0A54-4FA5-91B5-4D4339E8D9C8@cisco.com> <20141030003933.GS5186@eidolon>
To: David Lamparter <equinox@diac24.net>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JsC7cXyeK2k7QiCcI2ZCEcE0ymw
Cc: Ray Hunter <v6ops@globis.net>, "homenet@ietf.org" <homenet@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>, "Fred Baker (fred)" <fred@cisco.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Oct 2014 07:29:35 -0000

David,

> ::/0 from 2001:db8:1::/48 via PA-provider-1
> ::/0 from 2001:db8:2::/48 via PA-provider-2
> ::/0 from 2001:db8:cccc::/48 unreachable
> 2001:db8:cccc::/48 from 2001:db8:cccc::/48 via IPsec-gateway
> 2001:db8:cccc::/48 from ::/0 unreachable
> 
> Where the last route would prevent accidental leaking of packets onto
> the internet in case the IPsec gateway malfunctions.  (The 3rd route is
> redundant if there's no "::/0 from ::/0")
> 
> But - apart from ease of use for multiple prefixes, this can be done
> without SADR just fine, the only advantage is that there's full
> information regarding which source addresses work with which
> destinations.  If we get that to hosts, and into their source address
> selection, then we won something.

in a simple triangle topology:

   |            |
CE1      CE2
  \             /
   \           /
       IR1
         |
-----------------
   |
 Host

with PA1 and PA2 doing BCP38 filtering and a non SADR capable network, I would assert that you cannot do this without SADR.
IR1 load balances, and you could end up in a situation where IR1 load balancing would pick CE1 exit for PA2 source address, and CE2 exit for PA1 source address. with the result that whatever the host tried to do, all traffic would be black-holed by the ISP ingress filters.

with regards to getting SAS policies into hosts, that isn't necessary for the multi-homed to congruent networks case. it is needed in the walled garden cases (but there are some many other issues with walled gardens that I'm not sure the IETF should try to fix a broken business model). we do have a DHCP option already to configure a host's SAS table for this purpose. RFC7078.

cheers,
Ole