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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 13:29:03 +0100

> As an aside, and not that it really matters, but mutual 
  > authentication
  > generally doesn't happen.  PPP has had the ability to do mutual
  > authentication from day 1, but the most widely deployed 
  > versions of it
  > have steadfastly refused to support more than unidirectional
  > authentication.  What's more, ISPs seem to be singularly 
  > uninterested
  > in the concept: it means more information needs to be given to
  > customers, and is thus a support burden when those customers say,
  > "huh?"

=> Ok, but there are other networks and systems 
that require the mutual authentication. 'Mutual'
in the sense that the visited network authenticates
itself to someone that the user trusts (e.g. AAAH).
When that happens, the user gets information of 
success and access to the network. 

  > > Yes. Unless someone shows this is the only way, I rather want to
  > > see a solution that can accomodate IPv6 address autoconfiguration,
  > > and other methods.
  > 
  > I don't follow that at all.  In what way does 
  > draft-ietf-dhc-dhcpv6-22
  > inhibit the use of stateless address autoconfiguration?
  > 
  > Why would invention of an entirely new protocol here be a 
  > good thing?

=> 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??

  > > Then this would work, but I rather not say "the solution 
  > is to use Mobile
  > > IPv4".
  > > A simpler and more modular solution is better.
  > 
  > That's not at all what I'm saying.  I'm saying that *IF* you're
  > *ALREADY* using Mobile IP, *THEN* there doesn't appear to 
  > be any need
  > for PANA.  

=> For v4, not v6. There is no concept of AAA attached
to MIPv6, thank god for that.

The same is true for PPP.  If you're already using that,
  > then you don't need PANA. 

=> Because as you said PPP is not a good fit
for all types of link layers. 

 In both cases, you already have defined
  > mechanisms for authenticating the link, and additional mechanisms
  > aren't really needed.
  > 
  > In other words, I'm trying to infer the scope of PANA, 
  > since the scope
  > is not really very well defined.  I believe that the scope should be
  > limited to just the cases where *no* other solution is available.

=> 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.

Hesham

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 08:24:07 -0500 (EST)

> of DHCP that can stand alone without address config, 

Because doing so:

	- does not require the invention of a new discovery mechanism.

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

	- allows the use of existing software in some cases.

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.

> to MIPv6, thank god for that.

MIPv6 isn't quite in the same state as MIPv4 is; but for the time
being I agree that's a fair argument.

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?

> for all types of link layers. 

That's not at all what I'm saying.  What I'm saying is that *if*
you're already using PPP -- which is certainly a good fit for point-
to-point links -- *then* there's no need for an extra node
authentication mechanism.  I'm certainly not arguing that anyone ought
to be using PPP over Ethernet.  PPP over serial links works fine,
though.

In other words, there are certainly links that are already
authenticated and already use standards-track protocols to do so.  I'm
asking whether PANA should necessarily duplicate the functionality of
existing standards-track protocols in those cases.

In fact, I think that such a mechanism becomes troublesome precisely
because it duplicates the work already done.  How are the two
coordinated?  What does the network do if the two authentications
specify separate authorizations?  What happens if different identities
are used for each level?

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

> and flexible support due to access independence.

What's the specific benefit from duplicating existing mechanisms?  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.

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."

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.  So, you'd necessarily be asking the network
to provide unauthenticated access on the expectation that future
authentication would occur over some other mechanism.

I still don't quite see that as a selling point.

Is it possible to limit the scope of PANA to just the places where
there's a demonstrable need, or do we already have particular
solutions in mind when we write our requirements document?

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