IETF Logo Mail Archive

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

Michael Thomas <mike@mtcc.com> Tue, 23 October 2012 15:20 UTC

Return-Path: <mike@mtcc.com>
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 0017D11E80E7 for <homenet@ietfa.amsl.com>; Tue, 23 Oct 2012 08:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level:
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599]
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 vu7BE18a9rLp for <homenet@ietfa.amsl.com>; Tue, 23 Oct 2012 08:20:13 -0700 (PDT)
Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B59E11E80A6 for <homenet@ietf.org>; Tue, 23 Oct 2012 08:20:13 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9NFK7ZG023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 08:20:07 -0700
Message-ID: <5086B5A7.3040706@mtcc.com>
Date: Tue, 23 Oct 2012 08:20:07 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.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>
In-Reply-To: <CAKD1Yr0v3NdN+QCj=jFiZcv0ox1S-YAj29dZyMd6kAWAv723dg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1367; t=1351005610; x=1351869610; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20Lorenzo=20Colitti=20<lorenzo@google.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ggmj+iTnrAfXOhHcbb9SOUXzJ9BCxH2GXRMEAH6oYNg=; b=jE1cIwBk8DWpjklVJtCRQ/8Bh82+8VdAiiDiPZUq5MAkZ7j/vwPR/hiI5M gU9cZCf3gTVs8NqvVZ0GQKS5xsSDyEL9A73y4De/ArFjvDwmdzI68Zj7GxsZ MWISrHm7ZakVtwD/GdURvyJpB0fR4JpJp6cIMHND0VCULcYSruCFg=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Cc: homenet@ietf.org, james woodyatt <jhw@apple.com>
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 15:20:15 -0000

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

Mike

v2.23.0 | Report a Bug | By Email