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

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Oct 2009 18:43:09 +0200

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.

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Oct 2009 20:20:59 +0900

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

> happens between the client and the CPAA (and not, for instance, somehow 

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.

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

> Perhaps it would be better to not claim that 802.21 is the default 

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.

> I'd say Experimental extension is the right classification.

I agree on Experimental extension.

Yoshihiro Ohba

> 
> Jari
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pana
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Oct 2009 13:37:27 +0200

Yoshihiro,

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

OK.

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

I do not believe the security considerations of RFC 5191 are sufficient 
here. In 5191 the assumption was that you are in a local network. The 
threats when opening up PAAs to communication from the Internet are very 
different. Of course, we can hope that the mitigating mechanisms are 
largely the same. But you really need to highlight the security 
differences, and explain how PANA deals (or doesn't deal) with the issues.

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

OK

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

Good. Thanks for your quick response.

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Oct 2009 10:56:55 +0900

> differences, and explain how PANA deals (or doesn't deal) with the issues.

I agree that highlighting the security differences between
RFC 5191 and this draft is missing, and I will work on 
highlighting them.

Thanks,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Oct 2009 20:31:53 +0900

> differences, and explain how PANA deals (or doesn't deal) with the issues.

I agree that highlighting the security difference between
RFC 5191 and this draft is missing, and we will highlight it.

Thanks,
Yoshihiro Ohba