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

[Yoshihiro Ohba <[e-mail]>]

Hello Margaret,

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

(2010/11/20 2:50), Margaret Wasserman wrote:
> 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?

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.

> 
> 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?

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.
"
> 
> 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.

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.

> 
> 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?

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
> one PaC to use the same PRE? Further explanation would be helpful.

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.
"

> 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.

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.

> 
> 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)".

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.

> 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.

Again thank you for the review.

Best Regards,
Yoshihiro Ohba

> 
> Thanks,
> Margaret
> 
> 
> 
> 
> 
> 
> 
>