Re: [Pana] review of draft-ietf-pana-preauth

[Yoshihiro Ohba <yoshihiro.ohba at toshiba.co.jp>]

Thank you for the review.  Please see my comments below.

Jari Arkko wrote:
> 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).

Yes, the IP address of CPAA is the one that needs to be 
discovered and the PANA exchange for pre-auth happens 
between the client the CPAA.  We will clarify these two points.

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

I agree that the security considerations is thin.  This is 
because this draft inherits all security considerations 
applicable to RFC 5191.  I admit this inheritance is missing 
in the current draft and needs to be explicitly mentioned. 
I believe by adding the inheritance to the current text the 
above issue can be covered. What do you think?

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

You are right that 802.21-2008 does not define an 
information element specifically used for discovering CPAA. 
 I was thinking about the use of extended schema or vendor 
specific information element to define an information 
element for CPAA.  On the other hand, that is not not a 
standard way.  So I agree not to make 802.21 the default 
CPAA discovery 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.

I agree on Experimental extension.

Yoshihiro Ohba


> Jari
>
>
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www.ietf.org/mailman/listinfo/pana