Subject: on PANA justification was: RE: draft-ietf-pana-usage-scenarios-00 .txt

From: George Tsirtsis <[email-masked]>
Date: Fri, 8 Feb 2002 06:10:48 -0500

Well,

Whether the justification holds it is a matter of opinion and it seems we
have different ones. You guys that think there is no reason for PANA make
two assumptions:

1- PPP takes care of all point to point scenarios and can even run on top of
non point to point (e.g.: PPPoE)
2- 802.1X takes care of everything else.

The rest of us think that there is need for PANA because:

1- PPP does the job on point to point links but it is too much state and
thus is no good for non-point to point.
2- 802.1X does not take care of everything else because i) not all link
layers are 802 based and ii) 802.1X authentication is meaningless when what
you are looking for is access to IP layer services!
3- We need a lightweight authentication mechanism that works over any link
layer in a consistent way because authentication should become fundamental
part of the Internet architecture.

So, as long as there are enough people that think the 2nd set of arguments
is good enough justification for PANA we are going ahead and people with
objections should at some point give way to rough consensus.

The purpose of having BOFs before turning them into WGs is exactly to
establish that rough consensus. 

Following the decisions to go ahead, people who oppose the work have a very
hard case to make to convince others to stop the work and go home and IMHO
this should only happen if either significant part of the people that are
interested on the subject give up or the IESG thinks that this is going
nowhere. At the end of the day if you think that what PANA is trying to do
is nonsense let it be...if you are correct the work is likely to implode and
the protocol will never be used. 

George

-----Original Message-----
From: Jacques Caron [mailto:[email-masked]]
Sent: Friday, February 08, 2002 10:09 AM
To: Hesham Soliman (ERA)
Cc: Hesham Soliman (ERA); Yoshihiro Ohba; [email-masked]
Subject: RE: draft-ietf-pana-usage-scenarios-00.txt

At 10:38 08/02/2002, Hesham Soliman (ERA) wrote:
>=> I think we're revisiting the reasons for
>the creation of this WG, for some reason.
>I don't see the point since we already have
>a WG.

As I already pointed out, a WG or a charter is not a justification by 
itself. A WG might very well be created to try to solve a problem that was 
thought to exist, but actually doesn't :-/

Jacques.

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

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 08:10:34 -0500 (EST)

> non point to point (e.g.: PPPoE)

I don't understand why you keep asserting PPP over non-point-to-point
media as any sort of solution.  Those of us who are arguing that PPP
solves a class of problems (well, me) are saying that it solves
exactly those problems: it works for point-to-point links and includes
authentication that plays well with a AAA architecture.

> 2- 802.1X takes care of everything else.

802.1X works for very many of the cases that matter and (as a bonus)
includes linkages that work with AAA.  The rest is merely a deployment
problem.

> thus is no good for non-point to point.

Not an issue.  It works where it works and doesn't where it shouldn't.
Why would you ask more of it?  Why would that ever justify anything
else?  I agree that PPP on Ethernet is deep wrongness: don't do it.

> layers are 802 based

So, this would limit the scope of the usefulness of PANA down to
non-point-to-point (multiaccess) links that are not 802-based and do
not have existing AAA-supported authentication mechanisms.  Do we have
a list of the these network types that we're trying to fix?

Looking at the characteristics of the networks that actually need PANA
would probably be helpful.

> and ii) 802.1X authentication is meaningless when what

I still disagree with that assertion.  Link layer authentication is
what gets you the network access necessary to interact with network
layer (i.e., IP) services.  Why would anyone need something else?

> part of the Internet architecture.

This has yet to be shown to be a significant issue.

What we're talking about here isn't the authentication mechanism
itself, but rather just the *transport* for the authentication data.
What is the feature of per-link-layer authentication transports that
is so onerous that it compels a new protocol as a solution?

> the protocol will never be used. 

This is a nice theory, but it doesn't quite work in practice.  The
"best" protocol is not necessarily the one that wins.  *If* the
critics are right and *if* PANA is widely deployed by some 800lb
gorilla, then the rest of us will be saddled with additional protocol
that doesn't quite do the job and possibly causes other problems as
well.

On the other hand, it's certainly true that the critics are going to
get tired and just go home at some point ...

-- 
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: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 14:39:57 +0100

>2- 802.1X takes care of everything else.

Nope, 802.1x takes care of 802 media. A lot of other EAP encapsulations are 
still missing, both at the link layer (L2) and at the application layer. 
Any service, be it a network connection, an application, or anything else, 
should be able to provide standardized authentication services, preferably 
carrying EAP messages, since this allows easy extensibility, and use of 
existing standard back-end infrastructure (RADIUS, Diamater...).

Examples of places where EAP integration is missing:
- EAP for Bluetooth (my understanding is that this is coming along)
- EAP for MobileIP (v4 and v6)
- EAP for IGMP
- EAP for DHCP
- EAP for HTTP
etc.

If PANA can provide a solution for all these in a secure and robust manner, 
without any problems with NAT, proxies, and whatnot, great. But I think it 
might be quite a bit more complex than it might look at first sight :-(

>thus is no good for non-point to point.

What links are not point-to-point (from a L2 perspective) nowadays?

>you are looking for is access to IP layer services!

I agree with (i). As for (ii) I don't see how it's meaningless. If you want 
IP service, you definitely need Ethernet service first, don't you?

>part of the Internet architecture.

As I said above, I agree that any service requires AAA integration, and 
that indeed requires authentication integration on the "client" side. I 
also think that EAP works over any link layer, you just need to define the 
appropriate encapsulation for that :-)

>the protocol will never be used.

I don't say PANA is not a good thing. But I think trying to replace 
existing authentication technologies with PANA is not the right thing to 
do, and that it might be a lot more difficult to make it work securely and 
in all situations that it seems at first look, so using existing solutions 
where it's possible, and maybe having specific encapsulations rather a 
generic one that won't always work may be a better solution in many cases 
(though maybe not all).

Jacques.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Feb 2002 10:45:27 -0500

Hello Jacques,

On Fri, Feb 08, 2002 at 02:39:57PM +0100, Jacques Caron wrote:

[...]

> - EAP for MobileIP (v4 and v6)

Carrying EAP over IP-based protocol is not so easy task that one might
imagine in the first impression (I don't know what is the carrier for
EAP for Bluetooth).  Deep consideration for reliablity, congestion
control, MTU and fragmentation are at least necessary, based on the
fact that the EAP message size will be very large when chained
certificates are to be carried and that an EAP agent in the network
may be two or more IP hops away from the client device.  Modifying
each existing protocol to consider those things would need significant
design changes for the protocol itself, especially for Mobile IP,
IGMP, and DHCP which are not using a transport mechanism that can deal
with such things.  Thus, I don't think EAP integration in each
protocol is reasonable.  For EAP for HTTP, we already have some
description for differentiating PANA from web-based authentication in
section 3.2.1 of usage scenarios I-D.

Yoshihiro Ohba

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 22:53:46 +0100 (CET)

> thus is no good for non-point to point.

It might also be that layering PPP over a multi-access link *might* have
security issues.

> you are looking for is access to IP layer services!

By "IP layer services" do you mean "the service known as IP" or do
you mean fine-grain distinctions based on IP protocols and port numbers.
It seems like the "is 802.1X good enough for the links where it is implemented"
is based on the difference between those two.

> establish that rough consensus. 

While having period reaccuring "motivate why you exist WG" might seem
like a distraction or interference the inability by the WG to present a 
consensus view on how the work fits into the existing universe.
Once that view has been written down there is a quick "go read draft foo"
response to future questions.
So it would seem important that the WG do this piece.

   Erik