Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-preauth-09

[Ballot discuss]
RFC 5191 says the following:

10.2.2.  Flags

  There are 16 bits in the Flags field of the PANA message header.
  This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4
  ('P'), and 5 ('I') in Section 6.2.  The remaining bits MUST only be
  assigned via a Standards Action [IANA].

So to my understanding this document can not be published as an experimental and get the E bit assigned.

[Ballot discuss]
I have reviewed draft-ietf-pana-preauth-08, and have couple of
questions that probably need some clarification in the document:

- How does pre-authentication interact with the IP Reconfiguration
and the 'I' bit? (E.g., when the CPAA becomes the SPAA, can it tell
the PaC to do IP reconfiguration?)

- PANA can be used with non-key-generating EAP methods; however, it
seems pre-authentication requires a PANA SA? (since otherwise there
would be nothing to securely link the PNR/PNA exchange to the
earlier authentication)

[Ballot discuss]
I have reviewed draft-ietf-pana-preauth-08, and have couple of
questions that probably need some clarification in the document:

- How does pre-authentication interact with the IP Reconfiguration
and the 'I' bit? (E.g., when the CPAA becomes the SPAA, can it tell
the PaC to do IP reconfiguration?)

- PANA can be used with non-key-generating EAP methods; however, it
seems pre-authentication really cannot? (since there would be nothing
to securely link the PNR/PNA exchange to the earlier authentication)

[Ballot comment]
In section 6, I'm not clear what "authorized PaCs" are in this sentence:

  It is recommended that the authorized PaCs are limited to well-known
  IP networks for a given PAA.

IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "Message Flags" registry at
http://www.iana.org/assignments/pana-parameters/pana-parameters.xhtml

Bit Code Description Reference
--- ---- ------------------ --------------------
6 E prE-authentication [RFC-pana-preauth-08]

I have reviewed this document. The chairs believed that this draft could progress to the IESG, if certain scope reductions would be done and those are now in effect in -07.

Section 3: you should make it clear at the beginning what you expect as the output of the discovery process. I believe you are expecting an IP address of the PAA. Similarly, you should state that the PANA exchange happens between the client and the CPAA (and not, for instance, somehow proxied via SPAA).

The security considerations section seems thin. I'm sure there are more aspects to consider. For instance, what about DoS attacks where an evil client creates unnecessary state in a large number of networks? What about opening firewalls up for PANA traffic from the Internet -- it would seem that at the very least, there's an issue of fraudulent clients attempting to start EAP negotiations, creating partial session entries in PANA, AAA, and EAP state machines.

802.21 is mentioned to be the default discovery mechanism. But the text that says this is very thin on how 802.21 should be used. And the reference is informative. Maybe there's a part of 802.21 that explains exactly how to do it and what attributes are used. But I doubt it. Perhaps it would be better to not claim that 802.21 is the default mechanism.

Overall, I think this draft is reasonably simple and can move forward. However, given that we have no real specification of the discovery phase, and given the general lack of wide-spread working group interest, I'd say Experimental extension is the right classification.