Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00

Teco Boot <teco@inf-net.nl> Tue, 23 October 2012 17:25 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8EE11E80D5 for <homenet@ietfa.amsl.com>; Tue, 23 Oct 2012 10:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek-5s86e20tV for <homenet@ietfa.amsl.com>; Tue, 23 Oct 2012 10:25:31 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B10E11E80D1 for <homenet@ietf.org>; Tue, 23 Oct 2012 10:25:31 -0700 (PDT)
Received: by mail-ee0-f44.google.com with SMTP id d4so1759493eek.31 for <homenet@ietf.org>; Tue, 23 Oct 2012 10:25:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jxB4IazJLuaev8k1eZp2Bx3uruuPSvL2bs/1qNTIOEQ=; b=UqH52QWhYk4aFmQdFS5wvzKeR67rf01QqlU+IcxcFge753vPJLDGZMFMI5QqP5yKN8 n/dDy4JWN9xORoVxMSbK7OVVpK5cekaoZe5NuIFj+3ReIfZMES+0jruKJRx7DBfryHDM pP2tnJooZH8B6lR8D4xxotaHvmjPa9qyK/0y0b0jo1hysJjhawdLGqDvS6EHEMAY+5aq dBrmsGb4YVN1zB4b8Rshll/fud94drkG5tFoN99N8fq11+18SGBJu6QzSqvATXmBXgg2 Xg63lnb8v1Xk5woQ2nByV3q/xyngBeSSrGLNPfCs2Vu2V559CPGmnIS9zCs4vzycBRAV sZWQ==
Received: by 10.14.199.134 with SMTP id x6mr18074425een.31.1351013130539; Tue, 23 Oct 2012 10:25:30 -0700 (PDT)
Received: from [10.175.173.28] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id t7sm21847972eel.14.2012.10.23.10.25.29 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 10:25:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <5086D19C.4040002@mtcc.com>
Date: Tue, 23 Oct 2012 19:25:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <91FB983E-7D99-434E-9B09-B842D53F7A31@inf-net.nl>
References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <EMEW3|19238916f7ff9a0ada655caf80bba8cao9AAbJ03tjc|ecs.soton.ac.uk|10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <EMEW3|09bc323dc12a06be7c21e18f2752cd05o9LECn03tjc|ecs.soton.ac.uk|49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <C3720598-400C-4B83-9CEC-878B3FA8109E@ecs.soton.ac.uk> <EMEW3|3e5d3f7836c5b4ddbd99d74df88ecc6ao9LJ8r03tjc|ecs.soton.ac.uk|C3720598-400C-4B83-9CEC-878B3FA8109E@ecs.soton.ac.uk> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <CAKD1Yr0v3NdN+QCj=jFiZcv0ox1S-YAj29dZyMd6kAWAv723dg@mail.gmail.com> <5086B5A7.3040706@mtcc.com> <BCBB5332-50EF-40CB-A741-76CD8239CF2A@inf-n! et.nl> <5086D19C.4040002@mtcc.com>
To: mike <mike@mtcc.com>
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQmThvg274h8Mws8yGJ9CQknCNGAXZHsRo0uQ7JQFAcpL8TT1fG7a6WbufsyzYJboQuiUNaH
Cc: homenet@ietf.org
Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 23 Oct 2012 17:25:32 -0000

Op 23 okt. 2012, om 19:19 heeft mike het volgende geschreven:

> On 10/23/12 9:56 AM, Teco Boot wrote:
>> Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven:
>> 
>>> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
>>>> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
>>>> 
>>>>    No, sorry. Corporate VPN's using v6 and the lack of a coherent source address selection mechanism causes breakage in bizarre and unpredictable ways. You are not going to get the results you hope for if your mac uses an ISP prefix to get back inside the corpro firewall, uRPF if nothing else. SLAAC changes a lot of things over v4.
>>>> 
>>>> 
>>>> VPN clients already modify the routing table to ensure traffic going through the VPN goes through the VPN, to enforce policies around split tunneling, and so on. Mine even monitors the routing table for changes so it can act on them.
>>> Routing is irrelevant.
>>> 
>>>> Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here.
>>> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::,
>>> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your
>>> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues:
>>> 
>>> 1) the packet gets rejected via uRPF
>>> 2) the return packet splats against the inside firewall since it's not allowed outside
>>> 3) the packet makes it outside unarmored with sad faces from the security team
>> Employer should also provide 2001:yyyy::. Or make server accessible via Internet.
>> BRDP will handle this scenario nicely, also for existing hosts.
>> 
> Presumably, the reason it's behind the corpro firewall is because they don't
> want it accessible to the internet at large.
OK.

> I'm not sure if giving each host a
> prefix in 2001:yyyy's address space is scalable either for the hosts, the SLAAC
> announcements, or just carving up 2001:yyyy's addresses, especially if you have
> a large VPN population. I've done that myself, and I have doubts that it's the
> right approach.
I can't get why employer doesn't assign a 2000:: address to the server, other 
than test uRPF filters and get protocol designers crazy :-)

Teco

> 
> Mike
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet