Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

Ray Hunter <v6ops@globis.net> Mon, 05 August 2013 19:33 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4821F9DAA for <v6ops@ietfa.amsl.com>; Mon, 5 Aug 2013 12:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsvIuHdRhzIq for <v6ops@ietfa.amsl.com>; Mon, 5 Aug 2013 12:33:38 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBA521F9D9C for <v6ops@ietf.org>; Mon, 5 Aug 2013 12:33:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6013787007F; Mon, 5 Aug 2013 21:33:22 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chBUv1b8R-tR; Mon, 5 Aug 2013 21:33:22 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0AD74870077; Mon, 5 Aug 2013 21:33:22 +0200 (CEST)
Message-ID: <51FFFDFB.1040309@globis.net>
Date: Mon, 05 Aug 2013 21:33:15 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2013 19:33:40 -0000

Fred Baker (fred) wrote:
> A thought - tell me if this makes sense.
>
> In IPv4 networks, it is pretty common to in some way advertise the address of an internal-only server and then block access to it at the firewall.

This might be classified as a "leak" if they were 192.168/16 addresses.

But for GUA I see no harm advertising them, either in the namespace or
the routing space.

The information is invariant inside and outside: they're just not
reachable from everywhere.


>  If you want Cisco examples, try wwwin.cisco.com or irp-view13.cisco.com - dig them, ping them, and traceroute towards them. 

The examples you gave are equivalent of GUA, and Internet DNS.

> From my perspective, in IPv4 or in IPv6, the firewall rule makes little sense except as an additional defensive layer; one should not advertise the name to the great unwashed, and whether or not one does, one should give the system an address that is not advertised to the great unwashed.

Agreed. Agreed. It's not just security. It's to avoid confusion, cached
connections etc.

>  The next question, of course, is how to achieve that - does one only advertise half of their address space? 
Name space is the key here IMHO. Not just address space. You're into DNS
Bind "view" territory.

Especially when you have devices that wander regularly across the border
and that cache lots of information.

> Announce multiple prefixes? The ULA, whatever its other ills or uses may be, is an address that is not advertised upstream, and therefore a very logical address for an internal-only system in an IPv6 network.
True. But how does your machine know it is "internal only" or "external"
with VPN's, proxies, ALGs etc. etc.
And how long is that definition valid? When management gets outsourced
to supplier X?

> I scratch my head a bit on the vehemence that seems to come across in discussions of the ULA. I understand that there is a strong distaste for NATs, and I share it in the stateful case. It sounds a bit like the baby is being discarded with the bathwater, though, in the case of a system that one doesn't want to have communicating with the great wide world.
>
> Am I out to lunch? If so, in what way?

It's the confusion equivalent to the .local namespace that bothers me more.

I've seen people configure a server x.foobar.com in DNS that is not only
a different IP address on the inside and outside, it's a completely
different machine.
Or it might not be a different machine, but it's one machine with a
different physical interface with completely different firewall rules.

If you then have a cached bzr: checkout over ssh on your mobile device,
you're going to get confused machines and users.

A URL should be universal. Especially in a world that is becoming
increasingly mobile.

Once you start using ULA + NPT, all URLs and DNS entries become
equivalent to .local namespace + RFC1918, depending on your current
connection point relative to the NPT and the server. i.e. you've got no
idea if the NPT is in path or not. NPT doesn't translate the DNS AAAA
records. And DNS replies are cached.

Then you end up with all sorts of horrible kludges in the OS and apps to
detect whether your device is "on net" or "off net".
And then you start to wonder what is the definition of "on net" and "off
net" when there's so many different ways of traversing the boundary.

You could be on-net via proxy bypass for one HTTP site. And off-net for
another HTTP site via a proxy (steered via a .pac file).
And then you could be on-net for SSH (no proxy) via an IP direct to a
trusted 3rd party partner hosted system connected via a private gateway.
But off-net to a cloud service via an Internet firewall (steered via
private backdoor routes).

I did a project where I ended up putting in hundreds of external DNS
entries into an internal self-rooted DNS, together with hundreds of
firewall rules, and a proxy.pac file as long as your arm for proxy
bypass (which is then promptly mis-interpreted or ignored by every
different version of browser ever written)

And those entries had to be kept in synch every time the external info
changes. And tested for every browser release.

There lies operational madness.

> On Aug 5, 2013, at 1:23 AM, christian.jacquenet@orange.com wrote:
>
>> WG, 
>>
>> I've read (and commented) this draft some time ago. This document is useful and I think it should move forward.
>>
>> Regarding the ULA-related discussion, I don't think the document should simply ignore the potential use of such addresses, e.g., because our experience of providing IPv6 VPN service to our corporate customers since 2009 has shown that some of these customers ask for (and sometimes demand) a ULA-based addressing plan, mostly because these customers still think that private addressing provides some form of security. 
>>
>> This is partly an educational matter which we usually address by organizing training sessions within the enterprise, but the reality is that we could never avoid the discussion about ULA usage with these customers. And there are indeed a few of them who have chosen to go for an ULA addressing plan, at least for the duration of field trials or even pilot deployments.
>>
>> I would therefore expect the draft to mention ULA addresses. But I would also expect the draft to clearly discourage the use of such addresses, for the reasons mentioned by Lorenzo in his recent message. 
>>
>> For the sake of readability, I would (1) remove the ULA-related text from Sections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressing and Its Foreseen Implications" subsection in Section 2.6, which would better elaborate on the warnings highlighted in the aforementioned sections (e.g., Section 3.1's "use of PI space obviates the need for ULAs").
>>
>> A few additional typos:
>>
>> Section 2.1, page 7: "...after all initial *deployment* has been completed."
>> Section 2.2.2., page 9: s/recommend/recommended
>> Section 6.3, page 26: s/enterprise/university (second paragraph), s/campus enterprise/campus
>> Section 8, page 27: s/Jaquenet/Jacquenet 
>>
>> Cheers,
>>
>> Christian.
>>
>> -----Message d'origine-----
>> De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de Fred Baker
>> Envoyé : dimanche 4 août 2013 20:00
>> À : v6ops@ietf.org
>> Objet : [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
>>
>> This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6.  Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
>>
>> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>
> 	• Make things as simple as possible, but not simpler.
> Albert Einstein
>
>

-- 
Regards,
RayH