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

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 08:53:44 -0500

James,

I am trying to understand your point but I am failing. I think the
justification for PANA is very simple.

There are many protocols that support authentication as an add on, e.g.:
802.1X, MIPv4, PPP. There are also other protocols that one could add
authentication on them e.g.: DHCP.

The problem is that NONE of these protocols does not exist at all times and
in all scenarios. Maybe even worst some of these protocols may coexist
(e.g.: MIPv4 over PPPoE over 802.1X while DHCP is allocating the addresses)
in which case you may end up with multiple authentication sessions for the
same thing. On top of all this there are a number of scenarios that are not
covered by any of the existing memchanisms e.g.: static access to IP network
via multiple L2 hops, the hotel scenario etc.

Given also the principle that "A protocol should do one thing and do it
well",  PANA provides a way out of the current mess and confusion. It will
provide one way of doing authentication applicable to all scenarios. If that
is all you want to do then you will use PANA. In time, and if PANA is good
and useful, other protocols may also be revised to delegate the
authentication function to PANA but this will clearly take time and will
depend on how good a job we do here.

Is this clear at all or am I confused and you are trying to make a different
point altogether?

Regards
George

-----Original Message-----
From: James Carlson [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 1:24 PM
To: Hesham Soliman (ERA)
Cc: [email-masked]
Subject: RE: Concerns about draft-ietf-pana-requirements-00

Hesham Soliman (ERA) writes:
>   > 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??

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.

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

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?

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

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.

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

---

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

> justification for PANA is very simple.

Obviously, I don't think the justification is at all simple.

> authentication on them e.g.: DHCP.

Agreed.

> in all scenarios.

Is that an implementation problem, a deployment problem, or a protocol
problem?  I would argue that we can solve only the protocol problems
here.  (And, if we fail, perhaps make the other two a bit worse.)

> Maybe even worst some of these protocols may coexist

Exactly.  It is *only* those scenarios that I think are in scope for
PANA.  The other scenarios have solutions.

> Is this clear at all or am I confused and you are trying to make a different

I'm trying to make the point that in some cases, PANA will certainly
make the confusion you cite even worse.  For that hypothetical
MIPv4/PPPoE/802.1X+DHCP user, he'd have yet one more authentication
protocol in the mix.  How does that help?

PANA will very likely need discovery mechanisms and will need to run
before IP addresses are allocated (since this is usually security-
related).  This means that something like DHCP's hackery^Wmechanism to
send and receive IP datagrams with address 0 is needed.  Should PANA
duplicate this work?

More to the point: is it an intentional goal of this working group to
obsolete and replace all other link-layer related authentication
mechanisms?  Will we declare RFCs 1994, 2284, and 3118 obsolete?  If
so, is that really in-scope work for PANA (and does everyone agree
that it's ultimately the right thing to do)?  If not, then is this
really the all-encompassing solution that we're promising?

---

From: Jacques Caron <[email-masked]>
Date: Thu, 07 Feb 2002 23:05:47 +0100

Hi George,

At 14:53 07/02/2002, George Tsirtsis wrote:
>same thing.

Not the same thing. Each of the first three is a L2 (or L2 emulation) 
protocol. So they're direct point-to-point links between different sets of 
endpoints. DHCP is an altogether completely different issue (though an 
authentication extension for DHCP might be a good idea eheheh).

>  On top of all this there are a number of scenarios that are not

Can you describe what both of these are and what the issues are?

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com