Here are the rest of my review comments on this latest version.
-------------------
If multiple DHCP exchanges are occurring with multiple servers, both
IPv4 and IPv6 each needs to authenticate separately.
So, the same host needs to get authenticated twice if it is using both IPv4
and IPv6. This is a very unusual model for AAA. You need to update AAA
servers to allow "double login." And with that, it is already violating the
following requirement:
IPAuth-2 Must re-use existing SP Authentication
infrastructure (use
Radius Database) and allow mixed mode operation (eg PPP and IP) on
the same L3 edge device
-------------------
The client sends a DHCP Discover
message with an option specifying the authentication protocol as EAP
to find an available DHCP server. Any server that can that can
authenticate and address it responds with a DHCPEAP-REQ message.
A "DHCP server" sending a "request" to the "DHCP client"? This is so
not-DHCP. Current DHCP state machine does not allow that. So, basically you
are making a very significant change to the DHCP.
-------------------
I-D allows the DHCP server to respond to DHCPDISCOVER with "DHCPEAP-REQ" --
a brand new message (a request) sent in response. Again, breaking the state
machine and effectively inventing a totally new protocol that does not look
like DHCP anymore.
-------------------
In Figure 3, it seems like there is one DHCP client and two DHCP servers.
Within the same DHCP flow, some messages are responded by one server, some
by the other. This is certainly not standard DHCP.
-------------------
How is EAP-reauth initiated by the network is handled? The DHCP client needs
to receive an unsolicited DHCP request from the DHCP server out of blue.
This does not look like standard DHCP at all.
-------------------
How does DHCP satisfy the "orderly delivery" requirement imposed on the EAP
lower layers by RFC 3748?
An overall observation:
If we step back and look at the call flows, it is apparent that an EAP
call-flow is wedged into regular(*) DHCP call-flow, which freezes at some
point and resumes later. The wedged-in part is so different than DHCP, I
don't understand the value of using DHCP as the transport for that part (why
bother having such an impact on DHCP to the extent that it looks like a new
protocol?). But worse than that, the wedged-in part also leaks into the
regular DHCP call-flow (see how EAP Success/Failure gets transported over
DHCPOFFER) -- hence not so regular anymore (*).
Alper
Alper
> -----Original Message-----
> From: Alper Yegin [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 26, 2008 2:28 AM
> To: 'Richard Pruss'
> Cc: '[email protected]'; '[EMAIL PROTECTED]'
> Subject: RE: [Int-area] dhcp-auth
>
> I don't appreciate your comments. Let's stay on the technical course.
>
> > > Let's start just looking at the issues about Figure 3...
> > >
> > > - What is the DHCP-wise functionality of the NAS? Text claims it is
> > > a "DHCP
> > > relay" but I see it terminating some of the DHCP messages and also
> > > generating some other messages. This is not compliant with DHCP.
> > >
> >
> > As we explained to you many times most vendors BRAS's act as a DHCP
> > proxy and terminate all messages and look like a server to the client.
>
>
> That's not accurate according to Figure 3. I see "some" DHCP messages
> terminating on the NAS (e.g., DHCPEAP*) and "others" going through (e.g.,
> DHCPDISCOVER) within the same DHCP flow.
>
> I don't think it is as simple as your two-sentence explanation anyways. As
> requested earlier, IETF needs to see a document where this DHCP proxy
> model is defined. I'm aware of one DHCP proxy model and it is nothing like
> what your document is suggesting.
>
> Can you please send us a document that describes the DHCP proxy model?
> IETF needs to buy in the DHCP proxy model before any other proposal built
> on top of that gets accepted.
>
>
> > > - How does the NAS handle EAP retransmissions? It needs to send
> > > unsolicited
> > > DHCP messages to the DHCP client. This is not compliant with DHCP.
> > >
> > Actually that issue is open and we can discuss what a compliant
> > implementation would mean in terms of retransmission timers so that
> > right thing always happens at the right layer.
>
> OK, please explain.
>
>
> > > - I see NAS inserting additional DHCP option (EAP Success) on
> > > DHCPOFFER as
> > > it forwards that message from DHCP server to DHCP client. This again
> > > breaks
> > > DHCP.
> > >
> > As we explained to you many times most vendors BRAS's act as a DHCP
> > proxy and terminate all messages and look like a server to the client.
>
> Again, NAS does not really terminate "all" messages (see above). And this
> "box in the middle" inserting DHCP options towards the DHCP client breaks
> DHCP.
>
> > Lets take this to the dhcwg list as that is where the review happens
> > next week.
>
> Really? What happened to the escalation of this discussion to int-area and
> the outcome of the poll from last IETF? I hope Jari can clarify this.
>
> Alper
>
>
>
>
>
>
>
> >
> > - Ric
> >
> >
> >
> > >
> > > Alper
> > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
