Subject: [Pana] FW: AD Review comments on draft-ietf-pana-usage-scenarios-06.txt

From: Alper Yegin <[email-masked]>
Date: Fri, 21 May 2004 13:47:19 -0700

Please see below for Thomas Narten's review comments on the
usage-scenarios draft.

Chairs note: The current I-D seems like it will benefit from a re-write.
It has text that is not essential to answering the fundamental
questions. The text can be condensed. While doing that, we can also
reduce it to an appendix section in the requirements draft, and reduce
the document load.

- Chairs

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Friday, May 21, 2004 8:53 AM
To: [email-masked]; Alper Yegin
Cc: Margaret Wasserman
Subject: AD Review comments on draft-ietf-pana-usage-scenarios-06.txt

2004-05-20 review of -06:

Overall, a weak and unconvincing document. But probably harmless.

Need to get verification from DSL and CDMA2000 community on their
sections and whether pana is of any real interest to them.

abstract says:

>    Network access authentication is a function that is typically
>    required in most scenarios.

please change "most" to "many". Far from clear that this is required
in "most" scenarios.

Nits:

"PANA" acronym should be expanded in title (see ID nits)

The acronyms need definitions in some cases. E.g.:

>    MSC: Mobile Switching Center
>    MT: Mobile Termination
>    VLR: Visiting Location Register

mean nothing to me. There are others too that are not obvious. Expand
their meaning a bit?

normative references are not right. Many of the listed ones appear to
be non-normative.

>    The Extensible Authentication Protocol (EAP) [RFC2284bis] offers a
>    natural way to encapsulate many different authentication methods.
>    Among the various types of link-layers, only IEEE 802 defines how
to
>    carry EAP on the link-layer [802.1X].  Other link-layers resort to
>    using PPP/PPPoE [RFC1661,RFC2516] as a link-layer agnostic way of
>    carrying EAP. The ungainly insertion of this extra layer incurs
>    additional round-trips at connection time, generates overhead of
PPP
>    processing even for subsequent data packets, and forces the network
>    topology into a point-to-point model. EAP could achieve greater
>    applicability if it could be carried directly over IP. That way,
the
>    resulting IP packets could be carried over any link technology
>    without incurring additional cost or limitation on the
architectures.

would a PPP person agree with this characterization? (need to check)

>    In the absence of such lower-layer security and authentication
>    mechanism not only are service providers unable to control the
>    unauthorized use of their networks but also end-users feel insecure
>    about using such networks at all.  In order to support
authentication

I don't follow? End user can use SSH and be done with it... Where are
folks to afraid to use a network due to insecurity?

Thomas

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: James Carlson <[email-masked]>
Date: Fri, 21 May 2004 17:41:25 -0400

> would a PPP person agree with this characterization? (need to check)

As a lurking PPP person, I can say that I would not quite agree with
the characterization, and that it does seem like it needs some
wordsmithing.

PPP is a link layer protocol.  When you use EAP on PPP, you are using
EAP atop a link layer protocol, just as intended.  It's simply untrue
that only IEEE 802 is a link layer protocol.

The issue, of course, is that some folks seem to feel the need to run
one link layer atop another (e.g., PPP atop Ethernet) to achieve a
high level of overhead.  I do agree with the characterization of this
construct (particularly when done via PPPoE) as "ungainly."

A simple rewrite:

   The Extensible Authentication Protocol (EAP) [RFC2284bis] offers a
   natural way to encapsulate many different authentication methods
   over many different link layers, including IEEE 802 [802.1X] and
   PPP.

   Some implementations have layered PPP (itself a link layer) atop
   other link layers (such as IEEE 802) as a method of carrying EAP.
   Since EAP runs over IEEE 802, this is unnecessary and
   counterproductive.

-- 
James Carlson, IP Systems Group                <[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: Fri, 21 May 2004 17:41:25 -0400

A simple rewrite:

---

From: Alper Yegin <[email-masked]>
Date: Fri, 21 May 2004 15:05:59 -0700

>    Since EAP runs over IEEE 802, this is unnecessary and

Aside from the IEEE 802 and PPPoE context, there is also PPP over ATM,
and PPP over cdma2000 networks. 

Btw, even in IEEE 802-based DSL networks, using 802.1X would have issues
if it has to go through bridges (e.g., CPE modem, DSLAM).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 21 May 2004 15:05:59 -0700

Alper

---

From: Jari Arkko <[email-masked]>
Date: Sat, 22 May 2004 07:32:32 +0300

>    Since EAP runs over IEEE 802, this is unnecessary and

I agree with James' comments, but I would add that there's
always some overhead and roundtrips in the mechanisms used to
carry EAP and subsequent per-packet cryptographic protection.
Even PANA has it, although its certainly much better than with
PPP. Also, the original text seemed to be saying that with PPP
you are forced into a point-to-point model. That's true, but
isn't the same also true of PANA? I mean you will establish
a shared key between the client and the agent (or the EP). To
me this looks like a point-to-point model and I'm not sure you
can directly talk to the other nodes on the link. But James'
text avoids these problems, so if you'll just that you're fine.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 22 May 2004 07:32:32 +0300

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 23 May 2004 10:01:14 -0700

> text avoids these problems, so if you'll just that you're fine.

ARP as well as other direct communications among the nodes on the same
link works without passing through EP when PANA runs over a
multi-access link (this could be true even when EP is co-located with
access point, if the link-layer defines some sort of "side-channel").
In that sence PANA does not force a point-to-point model in
multi-access network unlike PPPoE.  However, the real issue might be
how to secure those direct communications and bootstrap the necessary
security associations for them when lower-layer is not secured, which
is out of the scope of the current PANA framework.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 23 May 2004 10:01:14 -0700

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 23 May 2004 16:06:46 -0700

> if it has to go through bridges (e.g., CPE modem, DSLAM).

Just to be fair, there is ongoing work, i.e., 802.1AE (MACsec) and
802.1AF (KeySec), in IEEE 802.1 Working Group to develop an
architecture and protocols in order to provide link-layer security
that work across IEEE 802 bridges (i.e., MACsec).  However,
considering maturity level of the work, I think PANA has more reality
in DSL environment (or PANA may be used even for bootstrapping MACsec
and KeySec in a future.)

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 23 May 2004 16:06:46 -0700

Yoshihiro Ohba