There are several concerns against standardizing
draft-pruss-dhcp-auth-dsl-02.
1. Architectural
When it comes to solving "distinct" fundamental problems (e.g., access
auth, mobility, configuration, QoS), IETF defines "distinct" protocols
for each. Piggybacking one over other for the sake of some optimization
(product/performance/etc) conflicts with the strategy we have been
following at IETF.
IAB document draft-iab-ip-config-00.txt is clear on that:
Network access authentication is a distinct problem from Internet
host configuration. Network access authentication is best handled
independently of the configuration mechanisms in use for the
Internet
and higher layers.
2. IETF principle
IETF has already defined a solution for the problem: PANA. As a
principle, IETF should first make an attempt to see if it really does not
solve the problem and consider refining its protocol if necessary.
Defining a new protocol each time someone has another solution is not
compliant with IETF's principle goal of achieving interoperability.
PANA already satisfies the requirements we received from DSLF.
3. Breaking DHCP
EAP and DHCP do not stack up well because none of the end points, state
machines, call flows match. And the proposal ends up breaking DHCP.
Specifically:
- DHCPOFFER does not deliver IP address, despite RFC2131 saying:
The server MUST return to the client:
o The client's network address, as determined by the rules given
earlier in this section,
- DHCP relay is inserting DHCP options (CHAP, EAP) when relaying
messages to the DHCP client. Relay is not supposed to do that.
- DHCP server receives the DHCPREQUEST but it does not respond to
it. Instead, DHCP relay generates the DHCPACK/DHCPNAK (See Figure 3).
- DHCP relay is generating DHCP messages (see Figure 5). Relays
are not supposed to do that. Although not documented yet, same
misbehavior is needed for EAP retransmissions, and re-authentication.
This is turning DHCP into a 3-party protocol.
- RFC3118 cannot be used when DHCP relay inserts options towards DHCP
client, removes options towards DHCP server, consumes some messages,
generates some messages. Basically, this is breaking the end2end model.
- DHCP server does not see the DHCPREQUEST, as it is consumed by
the relay (see Figure 5).
4. Failing DSLF requirements
Despite the clear statements in the DSLF requirements, this proposal is
not supporting authentication of the devices behind the HGW (CPE).
Instead, authors are denying the requirements:
IPAuth-8 Must handle L3 CPE device authentication and end-device
(PC)
user based authentication (likely with L2 CPEs in the latter
case)
IPAuth-9 Should be simple to implement on client (PC or CPE)
This is because it is not possible to modify deployed PC stacks with
that solution as DHCP is an internal part of the operating systems. On
the other hand, PANA can be supported at the application layer and it
does not require change to the IP stack.
5. IETF's IPR strategy
IETF has already produced an IPR-free solution to this problem: PANA. Why
should IETF not recommend use of PANA but instead rubber stamp an
IPR-encumbered solution?
6. Community pushback
Several people (excluding all PANA-related people) already spoke against
it.
Under the light of these issues, it is not clear why IETF is even
considering standardizing such a solution at this point.
DSLF in its liaison letter said they were "seriously considering" using this
solution, not like "demanding it be standardized." It's perfectly fine if
IETF analyzes the solution and concludes it has serious issues, and responds
with another alternative for DSLF's consideration.
Regards,
Alper
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
