Subject: [Pana] 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

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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 Oct 2006 01:03:48 +0300

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

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Oct 2006 13:21:39 +0200

I am fine with the approach that the option is
merely for PAA address discovery, not affecting
whether PANA is on or not. But I would like that
to be explicitly stated in the document. It would
also be useful to have a warning that there are
issues if you attempt to do otherwise.

Changes needed to state are likely fairly small.
If you submit the draft it probably appears when
the IETF starts and I can move the draft along
after that.
> "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."
This is a start. It defines what the nodes do, but I
would also like to see

1) What the PaC does when it receives the option
2) Explanation that the option is not used for turning PANA on/off,
along with the warning

--Jari