Here is my review.
Review of draft-pruss-dhcp-auth-dsl-02.txt
"For the latter, existence of a client using a given IP address can be
detected by a number of means, including Address Resolution Protocol
(ARP) [RFC1433], ICMP Echo/Echo Response [RFC0792], or Bidirectional
Forwarding Detection (BFD) [I-D.ietf-bfd-base]."
RFC 1433 is "Directed ARP". Did you mean to reference this specification
or RFC 826?
Section 2
Maybe I'm missing something, but this section doesn't describe the
problem statement with respect to access control. While PPPOE
prevents a client failing authentication from accessing the network
in any way (e.g. no IP, IPX, NetBEUI traffic), I am not clear
whether the goal is the same for this proposal, and if so, how it
is accomplished.
For example, is there an assumption on the NAS side that EAP is
being used for port access control? Or is this access control
based on the client MAC or IP address? Unlike with PPPoE, the data
packets aren't being encapsulated, so I don't understand how
access control decisions are to be enforced on the NAS. For
example, is there a filter operating on the NAS that only enables
packets to pass that originate from or are destined to an IP
address that was assigned as the result of a successful EAP
authentication?
Section 5.2
(DHCP messages continue normally from
this point forward if successful)
<------- DHCPOFFER (w/EAP Success Message)
(w/yiaddr)
DHCPREQUEST ------->
<------- DHCPACK
This flow seems to assume that an Access-Accept will always contain
an EAP Success message. This is not necessarily the case. It is
possible that it could contain an EAP Failure, for example (see
RFC 3579 Section 2.6.3). In that case, it is possible that the
DHCPREQUEST could be responded to with a DHCPNAK.
The retransmittion is handled by EAP as per Section 4.1 in [RFC3748].
In EAP, retransmission is handled by the authenticator, but in DHCP
doesn't the client do the retransmission? So how does this work?
How does the DHCP transport provide for in-order delivery? Is there
some kind of sequence number included in the DHCPEAP packets?
The identity hint information from [RFC4284] may be sent inside an
EAP-Request/Identity before the authentication conversation begins.
This allows replacement of PPPoE scenarios where PPPoE server
responds with a PPPoE Active Discovery Offer (PADO) packet that
advertises a list of available services.
I don't think that EAP can provide PPPoE PADO functionality based on
RFC 4284, which is only about realm advertisement, not general
capability discovery or negotiation.
Section 8.2
RFC 3118 provides a mechanism to cryptographically protect DHCP
messages using a key, K, shared between a DHCP client and Server,
however no mechanism is defined to manage these keys. Authentication
exchanges based on EAP have been built into authentication portions
of network access protocols such as PPP, 802.1X, PANA, IKEv2, and now
DHCP. EAP methods may provide for the derivation of shared key
material, the MSK and the EMSK, on the EAP peer and EAP server. This
dynamic key generation enables [RFC3118] protection and allows modes
of operation where messages are protected from DHCP client to DHCP
relay which previously would be difficult to manage.
Isn't the goal of RFC 3118 to protect exchanges between the DHCP client
and server (not between the client and relay)?
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
