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

["MORAND Lionel RD-CORE-ISS" <[e-mail]>]

 Hi Jari,

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

[Lionel] I had the same interpretation. This DHCP option is used as a
mean to retrieve the PAA address and not to mandate any specific
behavior of the DHCP client receiving this option. I'm not even aware
about such an ability to mandate specific client behavior by using a
DHCP option.
 
> >     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.

[Lionel] It's true that no guideline is provided about the behavior of
the DHCP client/server in the draft. At least, a strong recommendation
could be given:

"A PaC SHOULD request the PAA DHCPv4 Option in a Parameter Request List
as described in [RFC2131] and [RFC2132].
If configured with a (list of) PAA address(es), a DHCPv4 server SHOULD
send a client with the PAA DHCPv4 option, even if this option is not
explicitly requested by the client."

Of course, the same logic would apply for the IPv6 case.

If we can accept that a PaC may have the address of the PAA by
configuration means, the "SHOULD" seems more appropriate here than a
"MUST". 

Could it be acceptable?

BR,

Lionel
 
> >     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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> 
> _______________________________________________
> Pana mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pana