Subject: [eap] EAP IANA Considerations

From: [email-masked] (Bernard Aboba)
Date: Sat, 12 Oct 2002 20:03:58 -0700 (PDT)

It has been suggested that work on EAP might be sped up by early
completion of an EAP IANA Considerations document. In order to encourage
discussions on whether this makes sense or not, and if so, what the IANA
considerations document should say, I've put up a strawman document for
discussion:

http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-eap-iana-02.txt

Comments welcome.

---

From: [email-masked] (Simon Josefsson)
Date: Sun, 13 Oct 2002 07:05:22 +0200

> http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-eap-iana-02.txt

I still thinks this causes lots of work without no clear gain, and
even potentially harms progress of EAP implementations if at some
point in time the process of apointing and asking the Designated
Expert is slowed down due to the busy schedules people have.

What is the reason for all the manual work proposed in the draft?

If the real reason is that the EAP method type space is limited, why
not solve that technical problem with the technial solution, proposed
in your document, of using type 255 as an expanded type space with
room for 2^32 methods?  Then IANA can continue to simply register EAP
method types without going through the extra manual work each time.

Of course, EAP method types that are proposed as IETF standards need
extra scrutiny, but this is already taken care of by the IETF process.
IANA need not to do IETF's job.

This draft only causes more work for non-standards IETF EAP methods,
and this likely means that people will simply pick an unused EAP
method type and use it, which sort of destroys the whole point of
having a EAP method registry.

Sorry if this sounds harsh, but since I haven't understood the
rationale behind this document maybe my reasoning is flawed.

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 12 Oct 2002 21:32:20 -0700 (PDT)

> rationale behind this document maybe my reasoning is flawed.

The rationale is simple. IETF protocols creating new name spaces require
an IANA considerations section. RFC 2284 doesn't have an IANA considerations
section, so that there is currently no policy in place that describes how
protocol parameters should be allocated.

If you think that Designated Expert is unscalable, how about a situation
where the WG chairs are asked to rule on the allocation (that's what
happens in practice now).

I take it that you are advocating a First Come, First Served policy for
EAP method types?

---

From: [email-masked] (Simon Josefsson)
Date: Sun, 13 Oct 2002 08:07:02 +0200

> protocol parameters should be allocated.

OK, so the document is useful.  Only remains to argue about the
contents then. :-)

> happens in practice now).

Depends on what "rule on" implies.  I don't think there has to be any
serious technical evaluation before an EAP method type is allocated.

This is how I perceive the current situation -- some of the IANA
allocated types are only specified implicitly via running code.

If "rule on" only implies a way to stop completely bogus
registrations, it sounds fine.

> I take it that you are advocating a First Come, First Served policy for

Yes.  Unless there is a reason to do anything else, but I don't see
one here.

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 12 Oct 2002 22:44:51 -0700 (PDT)

> registrations, it sounds fine.

The problem is defining what "completely bogus" means. Is it:

a. A method that is non compliant with RFC 2284 in some respect
b. A method with a bad security flaw
c. A method that requires >N EAP type allocations?
d. A method that uses EAP for some inappropriate purpose?

And of course, who makes the decision, and on what basis?

Is a specification required for a "standard" allocation (37-254)? If so,
who says if it is good enough? If not, how do you decide what is "completely
bogus"? Is the answer different in the "expanded" space (Type >255)?

> Yes.  Unless there is a reason to do anything else, but I don't see

Are there limits to "first come, first served"? For example, can I request
allocation of Types 37-254? Or is it FCFS for 1 Type, but some other
policy for a block request? If so, how big is the block before the
alternate policy is triggered? And what is the alternate procedure?

And of course, there is a possible difference between "What the WG wants"
and "What the IESG will accept".

Welcome to the Wonderful World of IANA Allocation Policy :)

---

From: [email-masked] (Simon Josefsson)
Date: Sun, 13 Oct 2002 09:50:07 +0200

> And of course, who makes the decision, and on what basis?

I believe the process should be mechanistic, so the only reason to
stop allocating new EAP method types would if the name space would be
(nearly) exhausted.

> Is a specification required for a "standard" allocation (37-254)? 

This might be a good solution too.

> If so, who says if it is good enough? 

If it is put on the standards track?  Having 37-254 for standard track
types and 255+ for IANA FCFS allocation could fly.

> Welcome to the Wonderful World of IANA Allocation Policy :)

Making the IANA recommended practice draft say "allocate whatever
people want to allocate", does not raise these questions, I think.  If
the WG feels the name space is being exhausted too fast, it is
possible to ask IANA to stop allocate new method types and come up
with a technical solution (such as the 255 type) that allows IANA to
continue allocate types.  255 should be reserved for this purpose now
though.

Just my $.2. If having a designated expert feels more comfortable to
people I guess it would be fine too.

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 13 Oct 2002 06:49:30 -0700 (PDT)

> types and 255+ for IANA FCFS allocation could fly.

The "standard" space (37-254) need not necessarily require Standards
Action for allocation. For example, you could have IETF Consensus, or
Designated Expert, or Expert Review.

> continue allocate types.  255 should be reserved for this purpose now

The question is what hurdles are put in place for each space. Today, most
EAP Type allocations are made without a specification for uses which
appear to be vendor-specific. So creating a vendor-specific space for
"Private Use" should take much of the pressure of assignments from the
"standard" EAP Type space.

So the questions are:

a. What do you need to do in order to get a vendor-specific allocation?
   Answer: get an SMI enterprise code, then allocate types yourself.

b. What do you need to do in order to get an allocation from the
  "standard space" 37-254?

   1. Is a specification required?
   2. Does someone review the specification?
   3. Need the specification be published as an RFC? On the standards
      track?
   4. Does it make a difference if a block of Types is requested,
      instead of just a single Type?

c. What do you need to do in order to get an allocation from the
   "expanded" space 256+?
   1. Is this different from b?

> If having a designated expert feels more comfortable to

As you mentioned, there are implications from all of these choices.

---

From: [email-masked] (Pat Calhoun)
Date: 14 Oct 2002 08:38:42 +0000

> continue allocate types.  255 should be reserved for this purpose now

I think there's also an implied desire to maintain interoperability
among network elements. One can imagine that if we dish out identifiers
in a pseudo-random fashion, there would be more methods out there than
vendors would be willing to support. So who benefits? Certainly not the
internet community.

So I think in the interest of maintaining interoperability, we need to
set limits on what is assigned by the IETF. On the other hand, if there
does not exist a mechanism for vendors to create vendor specific
methods, address abuse will occur and then no one benefits (remember
RADIUS?). I am OK with this path, as long as these vendors promise not
to attempt to shove these methods down our throat later on :)

PatC

---

From: [email-masked] (Simon Josefsson)
Date: Tue, 15 Oct 2002 02:23:29 +0200

> vendors would be willing to support. So who benefits? Certainly not the

IETF standardizes the interoperable mechanisms.  Just because someone
has registered something with IANA doesn't mean everyone will have or
want to support it.

> So I think in the interest of maintaining interoperability, we need
> to set limits on what is assigned by the IETF. 

Yes, I agree, and we have standards track review for that.  I was
talking about what is assigned by IANA.

> On the other hand, if there does not exist a mechanism for vendors
> to create vendor specific methods, address abuse will occur and then
> no one benefits (remember RADIUS?). I am OK with this path, as long
> as these vendors promise not to attempt to shove these methods down
> our throat later on :)

The abuse is the problem, yes.  If IANA registrations are restricted,
people will simply pick a number and use it, but if the IANA registry
is open we at least prevent collisions and will have a contact address
for each mechanism.  The reverse problem is if vendors use an IANA
allocation as an "IETF blessing" of the approach in advertisement,
which is known to happen, but I think it is a lesser problem.