Thanks for a solid review.
[EMAIL PROTECTED] wrote, around 3/12/07 8:36 AM:
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?
Yes, thanks for catching that.
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?
IP session enforcement is well deployed today and there are a couple of
ways the various implementations handle IP sessions.
Possibly predominantly enforcement is to a MAC + IP host (or IP Subnet)
together, but with different security & redundancy implications you also
get:
VLAN+MAC+IP host (or IP Subnet)
VLAN+IP host (or IP Subnet)
IP host (or IP Subnet)
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?
Yes, the NAS will not pass packets to an IP session that it did not
allocate with DHCP and typically the NAS gets DHCP config from RADIUS
for in current implementations. Currently the NAS takes Option 82 puts
it into the Username field and does an Access Request. The Access
Access accept provides a profile that is used for the session and often
an IP address that is then returned in the DHCPOFFER. Access Reject
does result in a DHCPNAK.
The EAP is just adding a dialog with the CPE RW at this point.
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?
The EAP message retransmission is handled by the authenticator.
How does the DHCP transport provide for in-order delivery? Is there
some kind of sequence number included in the DHCPEAP packets?
No, we considered that at great length but we feel you can safely assume
that the Layer 2 wired switched system delivers packets in order.
If you are getting out of order in the access between the NAS and the
CPE you have far greater problems that EAP struggling.
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.
Yes. We will remove this in the next draft.
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)?
In the current implementation's the NAS's act as DHCP servers so for
that the scope of RFC 3118 will would just fine.
One thing that the comments on the draft has taught me is that talking
about the NAS as a relay is introducing confusion.
The NAS is either a DHCP server and getting IP address allocations from
locally managed pools or AAA, what allot of people call "proxy" instead
of relay. The difference is NAS overides the server to be itself and
can see all the DHCP messages as a result.
There is a draft on how to do this neatly but often implementations just
override the Server-ID.
http://ietfreport.isoc.org/ids/draft-ietf-dhc-server-override-05.txt
- Ric
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
