Subject: Re: Last Call: draft-ietf-pana-framework-06

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Mar 2006 10:24:55 -0500

Russ,

First of all, thank you very much for your input.

[1] I checked the latest 802.11ma draft and I confirm that the
description in pana-framework draft stating that Class 1 data frames
can be received in any state is not applicable any more.  So the
description on Class 1 data frame should be removed from the
pana-framework draft.

[2] It is not still clear whether running PANA over IEEE 802.1X
Uncontrolled Port is prohibited in IEEE 802.11i specification even in
the latest 802.11ma draft.

In the PANA WG session today, Bob O'Hara indicated the following text
in 802.11i, clause 6.1.4:

  "The IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if
  the Controlled Port is not enabled or if the MSDU does not represent
  an IEEE 802.1X frame."

On the other hand, 802.11i clause 5.4.2.2 describes as follows (I
checked the latest 802.11ma draft and the description remains the
same):

  "However, a given protocol may need to bypass the authorization
  function and make use of the IEEE 802.1X Uncontrolled Port."

According to the text, it is still possible to *interpret* this text
such that a give protocol like PANA is allowed to exchanged over
802.1X Uncontrolled Port.

[Note that several days after the email discussion over the EAP
mailing list quoted below, I had a short conversation on this issue
with Jesse Walker during IEEE 802 interim meeting in January in order
to follow-up the email discussion and understand the input from Jesse
more.  As far as I understand, he seemed to agree on this possible
interpretation while he mentioned that there is no existing 802.11i
implementation that uses 802.1X Uncontrolled Port for non-802.1X frame
exchange, but I may be still misunderstanding something.  Also, for
the sake of completeness of the email discussion over the EAP mailing
list, the following email that I sent in response to msg03872 should
be quoted as well:
http://lists.frascone.com/pipermail/eap/msg03879.html.]

The pana-framework draft is written based on the possible
interpretation, not based on existing 802.11i implementation.  As far
as the pana-framework draft is consistent with 802.11i specification
in terms of clause 5.4.2.2, whether an 802.11i implementation runs
PANA over Uncontrolled Port to bootstrap PSK mode seems to be an
implementation or deployment issue.

If the intent of 802.11i specification is to prohibit any data frame
other than 802.1X frame exchanged over Uncontrolled Port without any
exception, I'd suggest removing the above text in clause 5.4.2.2 from
802.11i specification.

Best regards,
Yoshihiro Ohba

On Mon, Mar 20, 2006 at 08:17:22PM -0500, Russ Housley wrote:
> Yesterday I had a discussion with Bernard Aboba about PANA.  I think 
> that Bernard was talking to me because of my involvement in IEEE 
> 802.11i.  It appears to me the PANA WG has a major problem.
> 
> The PANA WG seems to have a fundamental misunderstanding about 
> 802.11i.  I believe that the people involved in the PANA WG have been 
> told about their misunderstanding by the editor of 802.11i (Jesse 
> Walker from Intel), and it seems that this input was ignored this 
> input.  As a result the PANA specification that will not work at all 
> in wireless LANs that deploy 802.11i.
> 
> The PANA framework document states in Section 10.2.2:
> 
>    This model does not require any change in the current WPA and IEEE
>    802.11i specifications.
> 
> The PANA framework document also states in Section 10.2.2:
> 
>    The IEEE 802.11 specification [802.11] allows Class 1 data frames to
>    be received in any state.  Also, IEEE 802.11i [802.11i] optionally
>    allows higher-layer data traffic to be received and processed on the
>    IEEE 802.1X Uncontrolled Ports.  This feature allows processing IP-
>    based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA)
>    on IEEE 802.1X Uncontrolled Port prior to client authentication.
> 
> This is wrong on two points.  First, 802.11 ESS mode does not allow 
> data frames to be sent except in State 3.  I did not review the most 
> recent 802.11ma text, but I understand that this was recently 
> clarified in that document.  Also, 802.11i does not allow non-802.1X 
> traffic to be received or sent until completion of 802.1X 
> authentication and the 802.11i 4-way handshake.
> 
> This problem was discussed on the EAP WG in the following exchange 
> with Jesse Walker back in January:
> 
>    http://lists.frascone.com/pipermail/eap/msg03867.html
>    http://lists.frascone.com/pipermail/eap/msg03868.html
>    http://lists.frascone.com/pipermail/eap/msg03869.html
>    http://lists.frascone.com/pipermail/eap/msg03872.html
> 
> Given this situation, an Access Point that implements 802.11i will 
> silently discard all PANA traffic, and as a result, the PANA usage 
> scenarios 802.11i (either TKIP or CCMP, which are called WPA and WPA2 
> by the WiFi Alliance) cannot work as described.
> 
> Russ
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Mar 2006 11:45:25 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

e email discussion over
    Yoshihiro> the EAP mailing list quoted below, I had a short
    Yoshihiro> conversation on this issue with Jesse Walker during
    Yoshihiro> IEEE 802 interim meeting in January in order to
    Yoshihiro> follow-up the email discussion and understand the input
    Yoshihiro> from Jesse more.  As far as I understand, he seemed to
    Yoshihiro> agree on this possible interpretation while he
    Yoshihiro> mentioned that there is no existing 802.11i
    Yoshihiro> implementation that uses 802.1X Uncontrolled Port for
    Yoshihiro> non-802.1X frame exchange, but I may be still
    Yoshihiro> misunderstanding something.  Also, for the sake of
    Yoshihiro> completeness of the email discussion over the EAP
    Yoshihiro> mailing list, the following email that I sent in
    Yoshihiro> response to msg03872 should be quoted as well:
    Yoshihiro> http://lists.frascone.com/pipermail/eap/msg03879.html.]

So, the implementability of our specifications is a significant
concern.  If we do not expect there to be environments in which a
feature of our spec will be implementable, then we should remove that
feature.

Implementability is sufficiently important that RFC 2026 explicitly
gives the IESG the ability to request an implementation report even
for publication at proposed standard when it has questions about
whether a particular feature can be implemented interoperably.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Mar 2006 17:02:19 -0500

If implementability of the specification is an issue, my company has
an implementation of bootstrapping 802.11i PSK mode based on running
PANA over Uncontrolled Port.  The implementation works without
modifying a WiFi hardware or its firmware.  We have a plan to publish
the source code of the implementation in Open Diameter project.

Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 22 Mar 2006 17:19:29 +0200

We (Samsung) have an implementation as well.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Wednesday, March 22, 2006 12:02 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: Last Call: draft-ietf-pana-framework-06
>