[dhcwg] AD review of draft-ietf-dhc-paa-option-04.txt
Jari Arkko <jari.arkko@piuha.net> Fri, 06 October 2006 11:36 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVo0b-0005dl-AU; Fri, 06 Oct 2006 07:36:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVo0Z-0005dZ-GU; Fri, 06 Oct 2006 07:36:51 -0400
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVo0Y-0003Nm-0d; Fri, 06 Oct 2006 07:36:51 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A38C889837; Fri, 6 Oct 2006 14:36:48 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 615B38980A; Fri, 6 Oct 2006 14:36:48 +0300 (EEST)
Message-ID: <45263FB7.6050407@piuha.net>
Date: Fri, 06 Oct 2006 14:36:23 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: pana@ietf.org, Dhcwg <dhcwg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: Thomas Narten <narten@us.ibm.com>, Bernard Aboba <aboba@internaut.com>
Subject: [dhcwg] AD review of draft-ietf-dhc-paa-option-04.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org
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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg