RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt

["Alper Yegin" <alper.yegin at yegin.org>]

> 1. Clarify the role of this option in the decision
>     of the PANA client to start using PANA, and
>     the relationship of PANA usage in the network
>     to the DHCP server's decision to send this option.
> 
>     Currently, the document is silent on these points.

To me, the silence suggested (and I assumed) this option is merely used to
discover the PAA address. It does not mean that the host MUST use PANA if it
requests this option, or the access network MUST use PANA if it delivers
this option. I think this semantics is aligned with the use of other DHCP
options. 

Does this make sense? 

>     When I first read the document, I assumed that
>     the option is used as a dynamic mechanism to
>     tell the client when PANA is required in the
>     network.  However, the document does not say
>     that PANA-capable clients must always
>     request this option, and as a result, it is
>     not clear how clients find out. Similarly,
>     does the server send this if and
>     only if PANA is required to gain
>     access from this network? This seems
>     obvious, but the document says nothing.
> 
>     Even if we add the explanations,
>     it is not clear that the result is what
>     was expected. PANA usage makes
>     sense when there is no underlying
>     security. As a result, the DHCP exchange
>     that delivers this option is not secured from
>     a L2 point of view. This would allow a bidding
>     down attack where the client chooses
>     to use a lower-grade security mechanism or
>     perhaps no security at all.

Discovery phase is almost always unprotected with such network access
security schemes. I can only think of using public key crypto to secure the
discovery phase, and I'm not aware of any practical use of that in access
networks. Is this a threat that we need to live with, or do you think we can
do something about it?

>     One model where there are no bidding
>     down attacks is that the client is
>     configured to always run PANA,
>     and the DHCP option is used merely
>     to find the PAA, not negotiate the
>     use of PANA. But it was not clear if
>     this is what the WG wants.
> 
> 2. The security considerations section
>     needs to explain what the implications
>     of spoofed PAA addresses are. The
>     implications are also dependent on
>     the answers to issue 1; if the option
>     is used in a negotiation process the
>     security impacts need to be explained.
> 
> 3. In the abstract, s/many//
> 
> Given that the above issues are more about the
> PANA functionality than the DHCP encapsulation,
> I would suggest continuing this thread on the PANA
> mailing list.
> 
> --Jari
> 
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www1.ietf.org/mailman/listinfo/pana


_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana