Ric - From the DSLF liaison statement of Aug 30:
[...] the Architecture and Transport Working Group agreed to
seriously consider adopting a mechanism such as that proposed in
draft-pruss-dhcp-auth-dsl-01.txt or
draft-zhao-dhc-user-authentication-02. We understand that the
authors of these specifications intend to produce a combined
document soon.
Will draft-pruss-dhcp-auth-dsl-02 be this combined document? If not,
do you know when the combined document will be available for review
by the IETF?
- Ralph
On Oct 24, 2007, at Oct 24, 2007,5:09 PM, Richard Pruss wrote:
Yep, draft-pruss-dhcp-auth-dsl-01 does not have much text and
diagrams addressing relay agents. I am finishing up bits and
pieces in draft-pruss-dhcp-auth-dsl-02 and we put some clear
diagrams in for relay agents.
The fragmentation size problem may be addressed by the relay agent
having the role of EAP authenticator, as it splits the EAP traffic
into RADIUS out of DHCP, and DHCP messages should be normally sized
to the server.
Regards,
Ric
Ralph Droms wrote, around 25/10/07 6:54 AM:
Section 6.3 of draft-pruss-dhcp-auth-dsl-01 addresses how to fit
the EAP info into DHCP options, using RFC 3396.
However, there is also a recommendation, when using EAP, that the
server set the "Maximum DHCP Message Size" option to 1604.
Sending a DHCP message of this size may require fragmentation, but
DHCP relay agents cannot forward fragmented DHCP messages.
- Ralph
On Oct 24, 2007, at Oct 24, 2007,4:36 PM, Richard Pruss wrote:
Stig Venaas wrote, around 24/10/07 7:23 PM:
It's not as simple as just putting credentials into option 82
though.
For one thing there are strict limits on the size of DHCP
messages that
will limit what EAP or other mechanisms you can use. When the EAP
MTU is too small for the EAP message, you need multiple requests
and
responses to transport the message. This is not possible without
major DHCP changes. Hence you are not free to use what EAP
mechanisms
or credentials you like without major changes to DHCP. While
with say
PANA you could do that.
Stig section 6.3 of the currently posted -01 draft addresses the
size issue of EAP in some detail, it is not clear if you are
saying the proposed mechanism would not work.
Regardless of the mechanism if one thinks of this from the
implementation it should be no big deal as for EAP and RADIUS one
has to chop EAP into small enough chunks to get through
limitations in RADIUS (<253 bytes). While DHCP has similar
problems (<255 bytes), and one could can expect that most
networking companies would have implemented the lower common
denominator of RADIUS here.
Regards,
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
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
