Subject: Re: free prefix allocation service

From: Shannon -jj Behrens <[email-masked]>
Date: Fri, 4 Apr 2003 09:30:03 -0800

On Thu, Apr 03, 2003 at 03:44:29PM -0800, Michel Py wrote:
> http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt

Comments below ;)

> Nokia should not be the only company to provide free registration; as a
> matter of fact I think it would be good to have two servers.

Surely, it would be nice if anyone who wanted to could be such a server.

> Feel free to comment on the text, it does need polishing.

Now, concerning the draft, here are my comments.  Please have mercy, as this is
the first time I've ever responded with serious comments to a draft!

	C. Non-goals:

	Change the scope or usage of site-local addresses.

What do you mean by scope?  Also, you can scarcely change the usage since 
there is no *standard* usage.

	This document uses "site" having the same meaning as "end site" as
	   described in [IPV6POLICY].

It seems dangerous to start using a word in the wrong way, even if you document
it.  I imagine that it can only propogate the confusion, although I have no 
suggested solutions other than to use a different word.

	1.1 Rationale.

This section is a bit confusing.  Perhaps the following is better:

	The mailing list has expressed a desire that site-local prefixes have
	the following properties:  free, automatic, no registration, and 
	unique.  Since these properties are somewhat contradictory, it is
	necessary to partially compromise specific properties.  However, 
	multiple non-exclusive compromises are possible, so multiple 
	non-exclusive compromises are offered by this document.

Concerning:

	If the router has the capability of saving its
	configuration in non-volatile memory such as NVRAM, Flash,
	or disk file the site-local prefix MUST be saved as part of
	the configuration and the generation MUST happen only once;
	subsequent restarts MUST use the site-local prefix stored
	in the configuration.

I think that this text is not only necessary, but harmful.  The only reason
the prefix could change is if some nic's were added or removed.  If it is the
case that a nic is removed, the router must regenerate a new prefix.  I think
this goal is achieved by simply removing the text.

	1.2.2 Unregistered, free, unique, sequentially allocated:
	FEF0::/12

This is fine as long as Nokia never goes out of business (I'm not being snide,
I'm being practical).  My assumption accounts for this, but I don't think it's
a big deal.  I think we can trust Nokia to hand this over to another company if
the need ever arises.

	- Allocation is rate-limited at one prefix per day per IPv6
	/64 prefix or IPv4 address.

I can think of a few situtations where this limit would be too much.
Personally, I was thinking of simply requiring a valid email address, and
applying a minimal Turing test to make sure that a real person is making the
request.  As long as a real person is involved, he can request as many prefixes
(one at a time) as he wants.  This is not a big deal, though.

	Options a) and b) MUST NOT be available if the router does not
	have the capability of saving its configuration in non-volatile
	memory such as NVRAM, Flash, or disk file.

I think this goes without saying.  If it must be said, I don't think you need
to use "MUST NOT".  I think "will not" is sufficient.

	2.2 All IPv6 capable routers MUST implement a default black hole

I think SHOULD is sufficient.  If even 90% of routers implement this 
requirement, it will be enough.

In fact, I think sections 2.2 and 2.3 should be removed.  Afterall, routers 
internal to a site should route site-locals just fine (per Margaret Wasserman's
nesting ideas).  I would possibly replace this with non-normative text
suggesting that border firewalls and ISP's should filter this stuff.

	GUSL addresses MUST NOT be used for communication with other sites.
	Routers MUST NOT forward any packets with GUSL source or
	destination addresses outside of the site.

I'm personally not a fan of this.  I can understand trying to protect the DFZ,
but I think it should be perfectly fine to connect two sites using site-local
addresses and a tunnel.  Perhaps we should require that only unique (not 
probably unique) prefixes should be allowed to do this, though.

	6. Security considerations.

It'd be nice if there was text reminding people that site-locals don't 
necessarily provide security.
       
Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Apr 2003 20:42:15 +0200

Shannon -jj Behrens wrote:
> This is fine as long as Nokia never goes out of business (I'm not 
> being snide, I'm being practical).

:-)

In that eventuality there's one at http://gusl.nal.motlabs.com visible
both in v4 and v6.

Not that I support gusl proposal, I must first understand it, but it
seems to me that at least it raises new issues like how to coordinate
between several sites wanting to offer such a service.  Reliable
service and so on.  This is something enormous to deal with...

Back lurking...

Alex
GBU

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Apr 2003 10:49:33 +0200

I suspect there is a trivial DOS attack against this, despite the
one-per-day rule. We will need to think long and hard about how to make
such a system both idiot-proof and sabotage-proof.

   Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 07 Apr 2003 13:00:12 +0200

> such a system both idiot-proof and sabotage-proof.

the idiots are too smart for us.
put a human in the (control) loop; once we figure out that there's an 
attack, the proper countermeasure is usually obvious.

we don't need to coordinate between several sites if they hand out GUSL 
space from different prefixes; the RIRs (where it's far more critical) have 
running code for assignment escrow so that one RIR going out of business 
doesn't mean that customers lose the assignments they recieved earlier.

---

From: Shannon -jj Behrens <[email-masked]>
Date: Mon, 7 Apr 2003 09:48:45 -0700

Yes, surely.  That's why I advocated:

1) Each GUSL prefix should be taken out of an existing global unicast prefix
   that has been assigned to a company.  In this way, multiple parties could
   be delegating prefixes out of different prefixes.  The one drawback to this
   is that you wouldn't be able to tell a GUSL from a normal global unicast
   prefix, however, some may call that a feature.

2) The GUSL prefix should only be delegated to someone who could pass a silly
   "turing" test, such as those required when joining Slashdot.

Best Regards,
-jj