Subject: RE: Concerns about draft-ietf-pana-requirements-00

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 15:00:04 +0100

> => Because overloading DHCP, which is not necessarily
  > > needed in all IPv6 networks, is not a good thing either. 
  > > If it's a matter of having a separate module 
  > > of DHCP that can stand alone without address config, 
  > > then why call it DHCP??
  > 
  > Because doing so:
  > 
  > 	- does not require the invention of a new discovery mechanism.

=> Who needs to invent a new discovery mechanism ?

  > 
  > 	- does not require the invention of new relay mechanisms for
  >           non-local PAAs.

=> No one said that we will need a relay agent, we might
but it's not 100 % sure yet.

  > 
  > 	- allows the use of existing software in some cases.

=> The problem is that all the arguments above boil
down to an overloading philosophy which has caused
MIPv4 to be linked so tightly with AAA.
If You're arguing that The Dynamic Host Configuration
Protocol be used for access control because
they've already got a way of discovering the
server... That doesn't make sense to me.

  > 
  > I'm not arguing that this necessarily *should* be a DHCP extension;
  > instead I'm asking these questions in an attempt to get to 
  > the root of
  > the desire for a completely new protocol.  New protocols tend to be
  > somewhat expensive, and I think they should probably be avoided.

=> I agree and I think you're pursuing a noble goal.
Hopefully this discussion is helping.

  > The logical conclusion is rather odd though: MIPv4 has one AAA
  > solution (perhaps warty; that's not PANA's problem), MIPv6 uses PANA
  > for AAA.  Is that an improvement?

=> No the conclusion is: You can always use PANA if you
need it. Due to the MIPv4 mess, you don't need
it if you're running MIPv4. In every other case
you can use it (like IPv4 nodes that are not mobile
or IPv6, MIPv6).

  > I'm still failing to see why a duplicate mechanism is 
  > needed in cases
  > where there's already a viable mechanism in use.

=> No duplication is needed, replacement is 
a more appropriate word. See below.

  > 
  > > => One of the (hopefully) advantages of PANA
  > > is access independence. Why should we
  > > have multiple mechanisms when one can do
  > > the job. You might say that we already
  > > have the others, but I think the time has
  > > come for a clean architecture and 
  > > simplification. The benefits will be seen over
  > > time IMHO when it comes to ease of deployment
  > > and flexible support due to access independence.
  > 
  > What's the specific benefit from duplicating existing 
  > mechanisms?  

=> No duplication, we're simplifying things.

The
  > situation that I see looks something like this:
  > 
  > 	node <--PPP--> NAS <--AAA--> server
  > 	node <--other--> NAS <--AAA--> server
  > 
  > To this, we'd be adding:
  > 
  > 	node <--PANA--> NAS <--AAA--> server
  > 
  > Clearly, with suitable chosen options for each of the existing link-
  > layer-specific authentication schemes, the AAA bits on the wire
  > between NAS and authentication server are the same.  (For 
  > example, one
  > could simply say that EAP is the mechanism of choice going 
  > forward and
  > that all others are deprecated.  I don't see how that would be any
  > more disruptive than saying that a brand new protocol needs to be
  > deployed everywhere.)  There's thus no obvious benefit there.

=> OK how about this:

     node ----UMTS (HLR)--- internet
     node ---- PPP --- NAS----AAA

Why should an operator run two dual
authentication schemes ???
Do you see why we need to replace things
and offer a simple solution?

  > So, the benefits must be somewhere within that client node. 
  >  Inside we
  > have something like:
  > 
  > 	user-interface <-> auth-mechanism <-a-> link-layer
  > 	user-interface <-> auth-mechanism <-> PANA <-b-> ? <-> 
  > link-layer
  > 
  > Clearly, again, with suitable choices of authentication mechanisms,
  > the left-hand side doesn't change.  So it seems that the only thing
  > we're left with is avoiding the use of "EAP over X" for all 
  > X (linkage
  > 'a' above) and forcing a single "EAP over Y" for some chosen Y
  > (linkage 'b' above).  However, since we already have X deployed in
  > several non-trivial cases, what we're really saying is that we're
  > going to force everyone to implement "EAP over X and Y."

=> Ok but our deployment today is likely to increase.
Operators do often upgrade their systems to. 

  > 
  > The devil, of course, is in the details.  Consider what 
  > happens if AAA
  > were integrated into some existing technology, such as Frame Relay.
  > You'd certainly want to do the access determination at the 
  > point where
  > access is requested.  Unfortunately, a "global" (i.e. IP-based) PANA
  > solution doesn't work because you don't have an IP link until access
  > has already been granted.  

=> I can't really follow what do you mean
by 'not having an IP link till access is 
granted' ? You may have a specific network
in mind that I'm not aware of. 

Cheers,
Hesham

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 09:52:45 -0500 (EST)

> => Who needs to invent a new discovery mechanism ?

Some discovery is clearly needed: my only point there is that DHCP
happens to have its own discovery mechanism.

> but it's not 100 % sure yet.

If DHCP can be used as experience, I think relays are likely to be a
necessary evil.  Otherwise, you have to assume that the access points
necessarily implement the 'right' AAA protocol.

> server... That doesn't make sense to me.

Not exactly; I have no particular love of DHCP.  Instead, I'm
questioning why so many of the PANA participants appear (to me, at
least) to assume the use of a new protocol first, rather than
exploring (and exhausting) the options available with the existing
protocols.  DHCP happens to be one way to elucidate this.

On the overloading issue, I'm still unconvinced that this is
necessarily and obviously a bad thing.  It's clearly the case that
assigning IP addresses, installing/removing filters, creating CoS
associations and the like are all authorization functions that depend
on authentication.

So, where does this leave us?  Suppose we drain all authentication out
of the authorization mechanisms and PANA's authorization consists of
merely the boolean response proposed.  This means that (timewise) a
plausible exchange might be:

	User               Access Point
	---------          ------------
	Discovery     ->
	              <-   "I'm here, please do PANA"
	PANA request  ->
	              <-   "OK, I know you"
	DHCP discover ->
	              <-   DHCP offer
	DHCP request  ->
	              <-   DHCP ack

This leaves me confused.  How does the DHCP implementation (likely
separate and perhaps even located on a different node) know that the
user is authenticated at all?  If the DHCP implementation uses node
identity (say, mapping some NAIs to static addresses), how does it
know that the identity is valid without performing authentication?

At some point, I suspect these issues will force PANA to adopt all of
the "fine-grained" authorization mechanisms that these other services
already have.  At this point, I think you've reached convergence by
other means: PANA subsumes DHCP rather than DHCP growing PANA
appendages, for the net loss of requiring design, implementation, and
deployment of a whole new protocol in the process.

> you can use it (like IPv4 nodes that are not mobile

That assumes PANA deployment: the high hurdle here is adding a new
protocol.

> => No duplication, we're simplifying things.

If there's an existing mechanism in use, then this is clearly a
duplication.

> authentication schemes ???

I agree he would not want to do so.  I also agree that avoiding that
is an important goal.  I don't agree, though, that I can make the leap
from this to asserting that a new, global protocol is the only way to
do it.

> and offer a simple solution?

Sure; provide more detail:

	   <---end-to-end-use-of-EAP----->
	                            DHCP--AAA
	                           /
	node --- UMTS (HLR) --- access device -- internet

	   <---end-to-end-EAP--->
	                   ---- AAA
	                  /
	node --- PPP --- NAS --- internet

Thus, as I said, with suitable deployment you end up with exactly the
same authentication mechanism end-to-end, and thus the same
authentication infrastructure and the same maintenance.  The fact that
the specific encapsulation may vary a bit depending on the link
technology in use seems to me to be a boon rather than a detraction:
it means that the authentication and authorization functions can be
properly integrated in a manner that's dependent on link-layer
idiosyncrasies.

Consider, for example, the interaction between authentication
mechanisms that produce shared keys as a side-effect (e.g., SRP).  If
you do the authentication somewhere else, then you need some way of
moving those keys around to the place where they would be used.

Consider the slightly different implications of authorizations granted
by DHCP and those granted by PPP, where the former can assume (say) a
subnet behind the allocation and the latter cannot.

> Operators do often upgrade their systems to. 

You're going to have to wait for all of those old-fashioned Windows XP
systems to die off first.  For the "short" term (meaning, probably,
the next 10 to 20 years), I think you'll likely need both.

We're not discussing this as an "option:" it's the user's required
mechanism for access to the network.  What financial good is a network
deployment if only a very few people can access it?

> in mind that I'm not aware of. 

The example I gave (admittedly somewhat facetious but still not
completely unreasonable) assumed that the Frame Relay client would set
up his connection using an SVC and include authentication data in the
connection-setup message.  There's no way to send IP before the link
is established; only the low-level signaling messages are on the wire.

I suspect that analogous situations will continue to be true on other
link layers in the future.  I think PANA should probably consider the
implications of being unable to send *any* IP frames until a link-
layer authentication is performed.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677