Subject: more comments on draft-ietf-ipv6-unique-local-addr-00.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Sep 2003 23:42:20 +0200

The discussion about draft-ietf-ipv6-unique-local-addr-00.txt bothers 
me.

First of all, what are we talking about here? I see two needs:

a) the need for stable addresses
b) the need for private addresses

Let's first discuss a). The draft says that unique local addresses 
(ULAs) must not show up the global/public DNS so two-faced DNS must be 
used for these addresses. But how is a DNS server supposed to know 
whether the other end can reach the ULAs in question? Consider the 
situation where two organizations with their own ULA space merge. Hosts 
continue to have ULAs as before, but now there is a second range of ULA 
space that is reachable. But how does the DNS for organization A know 
that the resolving DNS for organization B should know the ULAs, as DNS 
B arrives at DNS A through the usual root, TLD and so on route, where 
only globally routable addresses are used.

I see only two solutions: huge amounts of manual configuration, or 
having the ULAs in the DNS, but not using them unless you have a route 
for them. This of course requires that all reachable ULA ranges are 
advertised to all hosts using an IGP.

The there is b). Obviously b) assumes a). However, a) certainly DOES 
NOT imply b). I'm afraid many people will prove to be incapable of 
making the distinction and end up creating a big old mess for 
themselves. It also occurs to me that using the routing system as 
access control isn't the best idea ever. Maybe it makes sense to set 
aside a range of private port numbers rather than a range of private 
addresses? (Simply filtering a single range of private ports in the 
network would certainly have made my life easier with all those worms.)

Finally, there is mention of using ULAs for VPNs. That makes no sense. 
If you use ULAs for a VPN, this means you can't reach the rest of the 
world over your VPN so you must do so using the unprotected 
connectivity that underlies the VPN. This is a huge security hole. VPNs 
should use regular routable address space.

BTW, we can probably repeat the entire discussion as soon as there is a 
locator/identifier separation proposal on the table as it is very 
likely that the identifiers for that will be drawn from a special range 
of address space.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Hans Kruse <[email-masked]>
Date: Mon, 08 Sep 2003 19:07:23 -0400

Comments below the two excerpts:

--On Monday, September 08, 2003 23:42 +0200 Iljitsch van Beijnum 
<[email-masked]> wrote:

> Let's first discuss a). The draft says that unique local addresses (ULAs)
> must not show up the global/public DNS so two-faced DNS must be used for
> these addresses. But how is a DNS server supposed to know whether the
> other end can reach the ULAs in question? Consider the situation where
> two organizations with their own ULA space merge. Hosts continue to have
> ULAs as before, but now there is a second range of ULA space that is
> reachable. But how does the DNS for organization A know that the
> resolving DNS for organization B should know the ULAs, as DNS B arrives
> at DNS A through the usual root, TLD and so on route, where only globally
> routable addresses are used.

> Finally, there is mention of using ULAs for VPNs. That makes no sense. If
> you use ULAs for a VPN, this means you can't reach the rest of the world
> over your VPN so you must do so using the unprotected connectivity that
> underlies the VPN. This is a huge security hole. VPNs should use regular
> routable address space.

>From what I have seen, these two are related and workable:

The use of VPNs it seems to me was mentioned when multiple organizations or 
multiple sites use local addressing; the VPN tunnels use global addresses, 
the "inner" packets use local addressing.  Once you do that, you can 
connect the DNS servers so Org A and B query each others "internal" servers.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Sep 2003 14:29:01 +0200

> only globally routable addresses are used.

When you merge two organisations that are both running 2 faced DNS, you
have to merge the two DNS setups at the same time as you merge the
internal routing domains. There's no way out of that, but when you
perform the merge, the difficulty you describe goes away, and although
there is manual work, it is vastly less than if you had to merge two
FEC0::/10s or two net 10s.

> advertised to all hosts using an IGP.

Of course. The IGP by definition knows all about the ULA prefixes.

> themselves. 

There is scope for an O'Riley book here, indeed.

> It also occurs to me that using the routing system as
> access control isn't the best idea ever. 

Agreed, but it's the best idea we have.

> Maybe it makes sense to set

Given that large transaction processing systems occasionally run out
of dynamic ports, I don't think this would fly. And port-agile worms
are hardly unknown.

> connectivity that underlies the VPN. 

No. As Hans indicated, this is for establishing multiple VPNs with
multiple business partners, quite independently of how you reach
the global Internet.

> This is a huge security hole. VPNs

That's a complete non-sequitur. The fact that I run 100 VPNs
in ULA space has no relevance to the security or insecurity of
my traffic to or from global space.
> likely that the identifiers for that will be drawn from a special range

Not in my view. That isn't a required property of identifiers, although
ULA addresses would make perfectly fine identifers.

  Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Sep 2003 15:14:47 +0200

On woensdag, sep 10, 2003, at 14:29 Europe/Amsterdam, Brian E Carpenter 
wrote:

>> Consider the

> internal routing domains.

You're right. Wrong example. ULAs are also supposed to be usable 
between consenting networks. In that case merging the name servers 
wouldn't be the first option.

> Agreed, but it's the best idea we have.

Isn't that the definition of "best idea ever"?  :-)

> of dynamic ports, I don't think this would fly.

Shouldn't RFC 1644 help against that? But probably not used, like so 
many good ideas...

Anyway, setting aside 25 or 12.5 % of the port number space shouldn't 
really create problems where there were none before, it would only make 
the existing problem slightly worse.

> And port-agile worms are hardly unknown.

The point is that it gets much easier to contain private services. 
Today, I have to filter 8 - 12 ports at the very least in order to be 
able to connect a Windows system right out off the box without it being 
infected before downloading the patches is even finished. With private 
ports, you get to plug and play without becoming a sitting duck.

> multiple business partners, quite independently of how you reach

There is more to IPsec than just tunnel mode.

> my traffic to or from global space.

This is how worms get into enterprise networks: remote user with VPN is 
infected over their regular unprotected connection and then continues 
to infect everything that's reachable over the VPN. This can and should 
be avoided by not allowing the remote VPN user to connect to the net 
outside of the VPN.

> ULA addresses would make perfectly fine identifers.

I don't think we are in a good position to determine this yet.