Subject: [dhcwg] AD review of draft-ietf-dhc-paa-option-04.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Oct 2006 14:36:23 +0300

I reviewed this spec and also got reviews from
Thomas Narten and Bernard Aboba. All
review input is collected below.

The following issues need attention in the
document before I can take it forward:

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.

    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.

    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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg