Subject: [Pana] draft-ohba-pana-relay-02.txt

From: Margaret Wasserman <[email-masked]>
Date: Fri, 19 Nov 2010 12:50:52 -0500

Hi Pana Relay Authors,

I've been asked to shepherd draft-ohba-pana-relay-02.txt for RFC
publication as a standards track document.  As part of that process, I
am required to perform my own review of the document before doing a
document write-up.  During my review, I found several issues that
should be resolved before this draft is published.

I'll start with a question: Before I read this draft, I was under the
impression that the Pana Relay would forward Pana messages between an
unmodified Pana Client (PAC) and an unmodified Pana Authentication
Agent (PAA), allowing Pana to be used on networks, such as 6lowpan
networks, that have multi-hop links.  However, the mechanism in this
draft requires modifications to the PAA to support a new message type
for relayed messages.  Are the expected users of this technology
aware that an updated PAA will be required?  Is there reason to believe
that updated PAAs will be available?

Now onto issues with the document text...

SUBSTANTIVE ISSUES:

S1) It appears that this document should be held for a reference to a
document coming from outside the IETF, the Zigbee IP Specification.  I
don't think we have a very good mechanism to do that, and I am not
sure why it is desirable for this document to be held for that
document.  Why wouldn't a reference to the 6lowpan documents suffice?

S2) The document says:

    The relay operation requires that a PANA session is initiated by the
    PaC, i.e., the first message that the PRE relays for any PANA  
session
    is a PCI (PANA-Client-Initiation) message.

It also indicates that the PRE does not maintain any per-PAC state.  It
is unclear to me that the PRE can ensure that the above text is true
without maintaining per-PAC state.

S3) I am not sure I understand what this text means:

    (a) The PAA uses the source IP address and the source port number of
    the PCI and the source IP address and UDP port number of the PRY to
    identify the PaC among multiple PCI messages sent from different
    PaCs.

Does it mean that all four values are used to differentiate the request?
So that we can support more than one PaC with the same address/port  
pair,
as long as they use different PREs?  Or only that we would allow more  
than
one PaC to use the same PRE?  Further explanation would be helpful.

EDITORIAL ISSUES:

E1) Some of the references in this document do not have corresponding
references within the text.  Specifically, RFC2464 and RFC5226.  These
references need to be removed, or references need to be added in the
text.

E2) The reference to RFC 2119 should be normative, not informative.

E3) There are many places in the text where acronyms are spelled out
in parentheses after the acronym, e.g. "PANA (Protcol for carrying
Authentication for Network Access)".  RFCs do this the other way
"Protocol for Carrying Authentication for Network Access (PANA)".

E4) AVP is not defined the first time it is used.

Please produce a new version of this document to address these issues,  
as well as the issues raised by Rafa Marin Lopez on the Pana list.  In  
the meantime, I will attempt to solicit a security reviewer for this  
document.

Thanks,
Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Nov 2010 08:42:57 +0900

Hello Margaret,

Thank you very much for shepherding the pana-relay draft and your
review.  Please see my comment below.

> that updated PAAs will be available?

Yes, main users (ZigBee IP) of this document are quite aware of the
required PAA update.  In fact, there were mainly two proposals to
support PANA in ZigBee, one does not require PAA update and the other
requires PAA update, and they finally selected the latter (i.e., the
relay mechanism described in this draft) mainly because of its
stateless feature for the relay with accepting the PAA change.

> document. Why wouldn't a reference to the 6lowpan documents suffice?

I understand the issue.. This is because the 6lowpan documents do not
discuss network access authentication.  BTW,
http://tools.ietf.org/html/draft-baker-ietf-core-11 mentions PANA in
the context of ZigBee IP without a reference to ZigBee IP.  I guess we
could do a similar way.  How about revising the text as follows?

"
For example, in ZigBee IP that uses 6LoWPAN [RFC4944], a joining node
(PaC) can only use a link-local IPv6 address to communicate with a
parent router prior to PANA authentication.
"
> PaC, i.e., the first message that the PRE relays for any PANA session

I understand your point.  It should be possible to relay PANA messages
for not only PaC-initiated PANA session but also PAA-initiated
session.  The only issue with relaying PAA-initiated session is that a
mechanism is needed for the PAA to detect the presence of PaC across
PRE.  I think that we can remove the above text, and add text to
mandate support of the relay operation for  PaC-initiated sessions, as
I don't think ZigBee IP is interested in supporting PAA-initiated
relay.  What do you think?  In any case PRE does not need to maintain
per-PaC state.

> Does it mean that all four values are used to differentiate the request?

Yes.

> So that we can support more than one PaC with the same address/port pair,
> as long as they use different PREs? Or only that we would allow more than

It meant to cover both.  Yes, I agree that we need to clarify this
point.  How about change the text as follows?

"
(a) The PAA uses the source IP address and the source port number of
the PCI and the source IP address and UDP port number of the PRY to
identify the PaC among multiple PCI messages sent from different
PaCs through the same PRE or sent from more than one PaC with the same
the source IP address and the source port number through different PREs.
"

> references need to be removed, or references need to be added in the

We will remove references to RFC2464 and RFC5226.

> E2) The reference to RFC 2119 should be normative, not informative.

We will change the reference to RFC 2119 normative.

> "Protocol for Carrying Authentication for Network Access (PANA)".

We will change the acronyms representations as you suggest.

> E4) AVP is not defined the first time it is used.

We will define PANA-Relay AVP in Section 2, with adding a citation to
Section 3.1 for more detailed definition of the AVP.

> the meantime, I will attempt to solicit a security reviewer for this 

Again thank you for the review.

Best Regards,
Yoshihiro Ohba