Subject: New charter

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 8 Jul 2002 12:11:55 -0700

Folks,

Please see the proposed new charter for the PANA Working
Group. Comments/questions welcome.

Chairs

-------------------------8<-------------------------------

PANA

In some scenarios, an IP-based device is required to authenticate
itself to the network prior to being authorized to use it. Today, such
authentication typically occurs at L2, e.g., via IEEE 802.1X or PPP.
Prior to being authenticated, a node's access to the network is
typically limited. For example, a node may only be allowed to send
traffic necessary to invoke an authentication protocol (possibly
enforced by L2 mechanisms). Once a device has been authenticated, it
would be granted broader access to the network (e.g., possibly
connectivity to the public Internet).

There are some scenarios where no L2 authentication is used. For
example, in some scenarios, IP connectivity is granted to anyone, but
only within a local scope (e.g., within a hotel or airport).  Broader
access is granted only after authentication. Because there is
currently no generic access protocol that allows a device to
authenticate itself to the network at layer 3 (i.e., at or above IP),
ad-hoc schemes are employed. For example, one (simplistic) approach is
to intercept all Web traffic and display a web page with instructions
for how to gain access.

The goal of PANA is to define a protocol that allows clients to
authenticate themselves to the access network using IP protocols. Such
a protocol would allow a client to interact with a site's back-end AAA
infrastructure to gain access without needing to understand the
particular AAA infrastructure protocols that are in use at the
site. It would also allow such interactions to take place without an
L2-specific mechanism.

Note that although PPP can provide the above functionality, PPP is
deemed an inadequate solution for a number of reasons.  Using PPP just
for client authentication requires extra round-trips, includes
overhead of PPP processing (for data packets), and forces the network
topology into a point-to-point model. For some wireless networks, the
point-to-point model is particularly inappropriate.

PANA will develop an IP-based protocol that allows a device to
authenticate itself with the network (and to a PANA Authentication
Agent (PAA) in particular) in order to be granted network access. For
simplicity, it is assumed that the PAA is attached to the same link as
the device (i.e., no intermediary IP routers). The PAA itself may
interface with other AAA backend infrastructures for authenticating
and authorizing the service being requested by the host, but such
interactions are transparent to the client.

The PAA does not act as an enforcement point to prevent unuauthorized
usage of the network. Enforcement points will generally be routers,
either on the same link as the client, or on another internal router
(e.g., a boundary router between the site and the Internet). When a
client succesfully authenticates itself to the PAA, enforcement points
will need to be suitably notified. The details of how this takes place
are outside of the scope of this WG, though a number of protocols that
might be used come to mind (e.g., RADIUS, Diameter, COPS, SNMP, etc.)

It is assumed that a client is already configured with an IP address
before using PANA. This IP address will provide limited reachability
to the client until it is authenticated with the PAA. Upon successful
authentication, client is granted broader network access possibly by
either a new IP address assignment, or by enforcement points changing
filtering rules for the same IP address.

PANA will not define any new authentication protocol nor does it
define key distribution, key agreement or key derivation protocols.
It is believed that PANA will be able to meet its goals if it is able
to carry EAP payloads. Note, however, that EAP may need to be extended
in order for PANA to meet the need for all of its intendend
usages. Such extensions are outside the scope of the PANA WG.

Deliverables of the WG:

AUG 02 Usage Scenarios and applicability statement
SEP 02 Requirements of PANA
NOV 02 Interaction of PANA with 802.1x and PPP
FEB 03 Protocol Specification
JUN 03 MIB for PANA Protocol

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jul 2002 07:59:12 +0859 ()

Alper;

> Group. Comments/questions welcome.

It is not clear what

	Today, such authentication typically occurs at L2,

means.

What is necessary is:

	user authentication to access L3

	L3 address for the terminal

which are fine to be called as "authenticate itself to the network
at layer 3 (i.e., at or above IP),".

However, it is also necessary (in wireless L2 case) to

	share a key for packet-wise authorization between a router
	and a terminal (essentially L2).

that it is not appropriate to call everything L3.

Finally, it is NOT essential whether a protocol for them has an IP
header or not, especially when packets with a lengthy IPv6 header
do not have meaningful IP addresses (such as DHCP discover). It is,
of course, a waste of packet exchange to fill the IP header with
meaningful IP addresses (such as DHCP discover).

> site. It would also allow such interactions to take place without an

ARP is not an L2-specifice mechanism. Right?

							Masataka Ohta

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 10 Jul 2002 17:56:15 -0700

Hello Ohta-san,

> authenticate itself to the network at layer 3 (i.e., at or above IP),

It (should?) mean what we are aiming is a L2-agnostic
solution. We can clarify this on the charter.

> and a terminal (essentially L2).

Sure. But note that packet-wise authorization can happen
either at the link-layer, or at the IP layer (e.g., using IPsec),
or even both..

> that it is not appropriate to call everything L3.

Packet-wise authorization is outside the scope of PANA.
PANA can be an enabler by bootstraping a trust relation
(with keys) though.

> meaningful IP addresses (such as DHCP discover).

If you are talking about using the protocol without a valid IP address
on the client (i.e., using unspecified source address), well this is
valid point to discuss.

But if you are talking about an authentication protocol that doesn't
even need an IP header (i.e., packet carried directly on mac frames),
then this doesn't sound like a L2-agnostic solution we are looking for.

> ARP is not an L2-specifice mechanism. Right?

Hmm, is this a trick question? :) Workings of the ARP (packet
format, etc.) depends on the underlying link-layer. Therefore
it's L2-specific.

alper

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jul 2002 11:24:30 +0859 ()

Alper;

> either at the link-layer, or at the IP layer (e.g., using IPsec),

That a purely link local communication occurs with IP headers
means that it is essentially L2.

> then this doesn't sound like a L2-agnostic solution we are looking for.

That is your confusion. See below.

> format, etc.) depends on the underlying link-layer. Therefore

Have you checked RFC826?

	Generalizations have been made which allow the protocol to be
	used for non-10Mbit Ethernet hardware.  Some packet radio
	networks are examples of such hardware.

	Generalization:  The ar$hrd and ar$hln fields allow this protocol
	and packet format to be used for non-10Mbit Ethernets.  For the
	10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>.  For
	other hardware networks, the ar$pro field may no longer
	correspond to the Ethernet type field, but it should be
	associated with the protocol whose address resolution is being
	sought.

The only assumption of ARP is that L2 has L2 addresses, which is why
address resolution is necessary.

ARP is not L2-specific.

							Masataka Ohta

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 10 Jul 2002 20:28:56 -0700

Ohta-san,

> associated with the protocol whose address resolution is being

Well, if you look at RFC1577 Classical IP and ARP over ATM
you can easily see how the protocol fields deviate. So, if I have to
change protocol fields for sending an ARP over different link-layers,
how can this be seen as link-layer agnostic?

> address resolution is necessary.

Even if this is the case, what does it tell us? I think I'm 
missing  the point you are trying to make.

alper

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jul 2002 15:02:47 +0859 ()

Alper;

> you can easily see how the protocol fields deviate.

The RFC is wrong to have assumed NBMA (Non Broadcast Multiple
Access).

> So, if I have to

To accomodate NBMA, some people were discussing to change IP
layers, of which RFC 1577 was the first step.

Fortunately, NBMA is dead forever. I helped a lot to kill it.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jul 2002 14:54:51 +0859 ()

Alper;

> missing  the point you are trying to make.

We can develop generic protocols in L2 without assuming IP headers.

							Masataka Ohta

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 Jul 2002 09:09:33 -0400

Ohta-san,

> We can develop generic protocols in L2 without assuming IP headers.

Does the above statement also hold when L2 itself is IP (I mean
IP-in-IP tunnel)?

It seems that PANA over IP-in-IP tunnel is out of the scope of the
current charter, but we may want to consider PANA over IP-in-IP tunnel
in the future.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 11 Jul 2002 17:44:23 -0700

Yoshihiro,

> current charter, but we may want to consider PANA over IP-in-IP tunnel

I didn't think the new charter disallows that. After all, an IP tunnel
is a link.. 

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 Jul 2002 21:09:52 -0400

OK.  

I may have overreacted to the wording "no intermediary IP routers".

Yoshihiro Ohba

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Jul 2002 13:41:29 +0859 ()

Ohba-san;

> Does the above statement also hold when L2 itself is IP (I mean

That something is not L2-specific means that it does not eliminate
IP-L2.

> current charter, but we may want to consider PANA over IP-in-IP tunnel

On the contrary, it seems to me that the current PANA charter is
narrowing the scope to be IP-L2-specific that it is OK as long as
IP is used even purely link local encapsulation such as IP-in-IP.

IP over IPsec between an access router and a terminal is such
an example.

							Masataka Ohta

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 Jul 2002 06:37:52 -0400

Ohta-san,

> That something is not L2-specific means that it does not eliminate

Could you elaborate on how authentication information is carried 
over IP-L2 without assuming IP headers?

Yoshihiro Ohba

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Jul 2002 16:47:08 +0859 ()

Ohba-san;

> over IP-L2 without assuming IP headers?

IP-L2 packets have IP-L2 headers, of course.

							Masataka Ohta