Skip to main content

Protocol for Carrying Authentication for Network Access (PANA) Relay Element
draft-ohba-pana-relay-03

Revision differences

Document history

Date Rev. By Action
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2011-07-05
03 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-07-05
03 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-07-03
03 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-07-01
03 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-07-01
03 (System) IANA Action state changed to In Progress
2011-07-01
03 Amy Vezza IESG state changed to Approved-announcement sent
2011-07-01
03 Amy Vezza IESG has approved the document
2011-07-01
03 Amy Vezza Closed "Approve" ballot
2011-07-01
03 Amy Vezza Approval announcement text regenerated
2011-07-01
03 Amy Vezza Ballot writeup text changed
2011-06-30
03 Jari Arkko State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-06-30
03 Jari Arkko Ballot writeup text changed
2011-06-23
03 Cindy Morgan Removed from agenda for telechat
2011-06-23
03 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-06-23
03 Stephen Farrell
[Ballot comment]
This used to be a discuss, but discussion with Jari convinced me
that's not needed.

I'm now ok with either the text agreed …
[Ballot comment]
This used to be a discuss, but discussion with Jari convinced me
that's not needed.

I'm now ok with either the text agreed via email or with saying
that PRE/PAA cryptographic security is optional, but if you do
implement something then you SHOULD do IPsec, or, since
this is no longer a discuss, with the current text. I do think
that a SHOULD somewhere will help interop so please
consider making one of the above changes.

--- original discuss ---

I hope this turns out to be a simple one - you almost, but not
quite, have a mandatory to implement security mechanism. I
think one would be good:

"Required security can be achieved by using IPsec or another
mechanism (e.g., via physical security, cryptographically-secured
link-layers, DTLS, etc.). " Pick one. It looks from this like
you've picked IPsec, if not why not and what other choice are you
making? If so, great - jusy say so.

--- original comment ---

(1) Why not specify how the PaC finds the PRE here?  Seems odd.

(2) This entire paragraph is very unclear. "The Session Identifier
and Sequence Number of a PRY message are set to zero.  A PRY
message is never retransmitted by the PRE or the PAA.  The PRE and
PAA do not advance their incoming or outgoing sequence numbers for
request when transmitting or receiving a PRY message.  Note that
the PANA message carried in a Relayed-Message may be retransmitted
by the PaC or PAA, leading to transmission of another PRY carrying
the same Relayed-Message." For example, you need to state a
condition that causes the session id and sequence # to be set to
zero - it surely doesn't happen just once every blue moon :-) (Same
thing is restated later.)

(3) It would be stronger to say that multiple proxys are a MUST
NOT.

(4) 1st sentence of section 3; s/must/MUST/?

(5) "Because the PREs and PAAs are used within an organization,..."
That should be clearer up front.
2011-06-23
03 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-06-23
03 (System) [Ballot Position Update] New position, No Objection, has been recorded for Ron Bonica by IESG Secretary
2011-06-23
03 Amy Vezza State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-06-23
03 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-06-23
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
03 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
03 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
03 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
03 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
03 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
03 Adrian Farrel [Ballot comment]
Section 1

  For example, in ZigBee IP

Needs a reference.
2011-06-22
03 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-21
03 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-06-21
03 Peter Saint-Andre [Ballot comment]
I support Stephen Farrell's DISCUSS.
2011-06-21
03 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-06-20
03 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-06-20
03 Sean Turner
[Ballot comment]
I had an issue with the first paragraph in Section 3 until I saw the exchange between Stephen and Alper.  Long way of …
[Ballot comment]
I had an issue with the first paragraph in Section 3 until I saw the exchange between Stephen and Alper.  Long way of saying I support Stephen's discuss.
2011-06-20
03 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-06-19
03 Pete Resnick
[Ballot comment]
Is the only reason for this protocol so that the PRE does not need to keep the context for every PaC request? I …
[Ballot comment]
Is the only reason for this protocol so that the PRE does not need to keep the context for every PaC request? I don't quite understand why the PAA has to be involved in this at all except to turn around the information for the PRE to find the PaC.
2011-06-19
03 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-06-18
03 Stephen Farrell
[Ballot comment]
(1) Why not specify how the PaC finds the PRE here?  Seems odd.

(2) This entire paragraph is very unclear. "The Session Identifier …
[Ballot comment]
(1) Why not specify how the PaC finds the PRE here?  Seems odd.

(2) This entire paragraph is very unclear. "The Session Identifier
and Sequence Number of a PRY message are set to zero.  A PRY
message is never retransmitted by the PRE or the PAA.  The PRE and
PAA do not advance their incoming or outgoing sequence numbers for
request when transmitting or receiving a PRY message.  Note that
the PANA message carried in a Relayed-Message may be retransmitted
by the PaC or PAA, leading to transmission of another PRY carrying
the same Relayed-Message." For example, you need to state a
condition that causes the session id and sequence # to be set to
zero - it surely doesn't happen just once every blue moon :-) (Same
thing is restated later.)

(3) It would be stronger to say that multiple proxys are a MUST
NOT.

(4) 1st sentence of section 3; s/must/MUST/?

(5) "Because the PREs and PAAs are used within an organization,..."
That should be clearer up front.
2011-06-18
03 Stephen Farrell
[Ballot discuss]
I hope this turns out to be a simple one - you almost, but not
quite, have a mandatory to implement security mechanism. …
[Ballot discuss]
I hope this turns out to be a simple one - you almost, but not
quite, have a mandatory to implement security mechanism. I
think one would be good:

"Required security can be achieved by using IPsec or another
mechanism (e.g., via physical security, cryptographically-secured
link-layers, DTLS, etc.). " Pick one. It looks from this like
you've picked IPsec, if not why not and what other choice are you
making? If so, great - jusy say so.
2011-06-18
03 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-06-10
03 David Harrington Request for Last Call review by TSVDIR Completed. Reviewer: Yoshifumi Nishida.
2011-06-08
03 Amanda Baber
IANA has questions about the IANA Actions in this document.

IANA understands that, upon approval of this document, there are two
IANA Actions that must …
IANA has questions about the IANA Actions in this document.

IANA understands that, upon approval of this document, there are two
IANA Actions that must be completed.

First, in the Message Types registry in the Protocol for Carrying
Authentication for Network Access (PANA) Parameters registry located at:

http://www.iana.org/assignments/pana-parameters/pana-parameters.xml

a single, new message type will be added as follows:

Value [ TBD ]
Name: PANA-Relay

IANA QUESTION --> How should the following field in the registry be
filled in?
Req/Ans: [ ??? ]

Abbrev: PRY
Reference: [ RFC-to-be ]

IANA notes that the authors request the value "5" for the Value of this
Message Type.

Second, in the AVP Codes registry in the the Protocol for Carrying
Authentication for Network Access (PANA) Parameters registry located at:

http://www.iana.org/assignments/pana-parameters/pana-parameters.xml

two new AVP Codes will be added as follows:

Code: [tbd2]
Attribute name: PaC-Information AVP
Reference: [ RFC-to-be ]

Code: [tbd3]
Attribute name: Relayed-Message AVP
Reference: [ RFC-to-be ]

IANA notes that the authors have requested codes "10" and "11" for
[tbd2] and [tbd3] respectively.

IANA understands that these two actions are the only ones required upon
approval of this document.
2011-05-31
03 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alan DeKok
2011-05-31
03 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alan DeKok
2011-05-27
03 Wesley Eddy Request for Last Call review by TSVDIR is assigned to Yoshifumi Nishida
2011-05-27
03 Wesley Eddy Request for Last Call review by TSVDIR is assigned to Yoshifumi Nishida
2011-05-25
03 Amy Vezza Last call sent
2011-05-25
03 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Protocol for Carrying Authentication for Network Access (PANA) Relay Element) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Protocol for Carrying Authentication for Network Access (PANA) Relay
  Element'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document specifies Protocol for carrying Authentication for
Network Access (PANA) Relay Element functionality which enables PANA
messaging between a PANA Client (PaC) and a PANA Authentication Agent
(PAA) where the two nodes cannot reach each other by means of regular
IP routing.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ohba-pana-relay/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ohba-pana-relay/


No IPR declarations have been submitted directly on this I-D.


2011-05-25
03 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2011-05-25
03 Jari Arkko Ballot has been issued
2011-05-25
03 Jari Arkko Created "Approve" ballot
2011-05-25
03 Jari Arkko Placed on agenda for telechat - 2011-06-23
2011-05-25
03 Jari Arkko Last Call was requested
2011-05-25
03 (System) Ballot writeup text was added
2011-05-25
03 (System) Last call text was added
2011-05-25
03 (System) Ballot approval text was added
2011-05-25
03 Jari Arkko State changed to Last Call Requested from AD Evaluation.
2011-05-25
03 Jari Arkko Last Call text changed
2011-05-25
03 Jari Arkko Ballot writeup text changed
2011-05-25
03 Jari Arkko Ballot writeup text changed
2011-05-25
03 Jari Arkko Ballot writeup text changed
2011-05-25
03 Jari Arkko State changed to AD Evaluation from Publication Requested.
2011-05-05
03 Cindy Morgan
> 1.a)
>
> Who is the Document Shepherd for this document?

Margaret Wasserman

> Has the Document Shepherd personally reviewed this version of the …
> 1.a)
>
> Who is the Document Shepherd for this document?

Margaret Wasserman

> Has the Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this version is
> ready for forwarding to the IESG for publication?

Yes. I provided significant feedback on the document based on my
review, and all of my concerns were addressed.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members?

Notification of the planned publication of this document was sent to
the old PANA WG mailing list in November 2010. Significant issues
were raised as a result of that notification, and discussed on that
list. All issues raised in that discussion have been resolved.

While a closed WG doesn't have a chair to determine consensus, it is
my opionion that this document now represents the consensus of the
interested parties that discussed the document on the old PANA WG
mailing list.

In addition to those implementing the protocol, the document has been
reviewed by Alan DeKok, Rafa Marin Lopez and Margaret Wasserman.

> Does the Document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No

> (1.c)

> Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective, e.g.,
> security, >operational complexity, someone familiar with AAA,
> internationalization or XML?

No

> (1.d)
>
> Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director and/or
> the IESG should be aware of? For example, perhaps he or she is
> uncomfortable with certain parts of the document, or has concerns
> whether there really is a need >for it. In any event, if the WG has
> discussed those issues and has indicated that it still wishes to
> advance the document, detail those concerns here.

No

> Has an IPR disclosure related to this document been filed? If so,
> please include a reference to the disclosure and summarize the WG
> discussion and conclusion on this issue.

No

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with
> it?

The document was developed by a number of individuals as an extension
to PANA [RFC 5191] after the pana WG had concluded. It has been
discussed on the old PANA WG mailing list. In addition, it has been
implemented by 9 vendors and proved interoperable amongst those
vendors.

> (1.f)

> Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It should
> be in a separate email because this questionnaire is entered into
> the ID Tracker.)

No

> (1.g)
>
> Has the Document Shepherd personally verified that the document
> satisfies all ID nits? (See the Internet-Drafts Checklist and
> http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
> enough; this check needs to be thorough.

The document has three lines that are too long. This issue will be
addressed when AD Review, IETF LC or IESG Review comments are
resolved.

> Has the document met all formal review criteria it needs to, such as
> the MIB Doctor, media type and URI type reviews?

Yes. We also requested a security directorate review and the document
was reviewed by Alan DeKok on behalf of the security directorate.

> (1.h)
>
> Has the document split its references into normative and informative?

Yes

> Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No

> If such normative references exist, what is the strategy for their
> completion?

[N/A]

> Are there normative references that are downward references, as
> described in [RFC3967]?

No

> If so, list these downward references to support the Area Director
> in the Last Call procedure for them [RFC3967].

N/A

> (1.i)
>
> Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body of the
> document?

Yes

> If the document specifies protocol extensions, are reservations
> requested in appropriate IANA registries?

Yes

> Are the IANA registries clearly identified?

Yes

> If the document creates a new registry, does it define the proposed
> initial contents of the registry and an allocation procedure for
> future registrations?

[N/A]

> Does it suggest a reasonable name for the new registry? See
[RFC5226].

[N/A]

> If the document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG can
> appoint the needed Expert during the IESG Evaluation?

[N/A]

> (1.j)
>
> Has the Document Shepherd verified that sections of the document
> that are written in a formal language, such as XML code, BNF rules,
> MIB definitions, etc., validate correctly in an automated checker?

[N/A]

> (1.k)
>
> The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up?
> Recent examples can be found in the "Action" announcements for
> approved documents. The approval announcement contains the following
> sections:

Technical Summary

The document specifies PANA Relay Element (PRE) functionality which
enables PANA messaging between a PaC and a PAA where the two nodes
cannot reach each other by means of regular IP routing. For example,
a joining node (PaC) may only be able to use a link-local IPv6 address
to communicate with a parent router prior to PANA authentication. The
PAA typically resides in a 6LoWPAN Border Router which is often
multiple IP hops away from the PaC. The PRE implemented on the parent
router is used for relaying PANA messages between the PaC and the PAA
in this scenario.

Working Group Summary

The document was developed by a number of individuals as an extension
to PANA [RFC 5191] after the pana WG had concluded. It has been
discussed on the old PANA WG mailing list.

Document Quality

The protocol has been implemented by 9 vendors and proved
interoperable amongst those vendors as part of the ZigBee IP stack
development process. PANA relay will form an integral part of the
authentication process for the ZigBee IP stack.
2011-05-05
03 Cindy Morgan Draft added in state Publication Requested
2011-05-05
03 Cindy Morgan [Note]: 'Margaret Wasserman (margaretw42@gmail.com) is the document shepherd.' added
2011-02-03
03 (System) New version available: draft-ohba-pana-relay-03.txt
2010-12-16
03 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Alan DeKok.
2010-11-22
03 Samuel Weiler Request for Early review by SECDIR is assigned to Alan DeKok
2010-11-22
03 Samuel Weiler Request for Early review by SECDIR is assigned to Alan DeKok
2010-10-20
02 (System) New version available: draft-ohba-pana-relay-02.txt
2010-10-20
01 (System) New version available: draft-ohba-pana-relay-01.txt
2010-09-21
00 (System) New version available: draft-ohba-pana-relay-00.txt