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

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.

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.

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.


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.

Isn't that the definition of "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.)

Given that large transaction processing systems occasionally run out
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.


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.

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

There is more to IPsec than just tunnel mode.


This is a huge security hole. VPNs
should use regular routable address space.

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.

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.


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.

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

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


--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to