Subject: RE: [Int-area] DCHP-based authentication for DSL?

From: "Peter Arberg" <[email-masked]>
Date: Tue, 23 Oct 2007 02:16:46 -0700

Hi,
 
I will like to give a late input to this discussion.
 
I do believe the DHCP based authentication is a preferred solution
if we believe that per subscriber authentication is needed in a 
DSL broadband network.
 
BRAS, BNG or NAS equipment, or what we call it, has always 
been optimized towards subscriber bring up rate, and the model with
PPPoE, with what I will call a link negotiation part, a authentication
part and finally a ip-address allocation part has been the model for
optimization for a long time.
 
The fact that the BRAS/IP Edge equipment in this case do not have
to "distribute" a full subscriber IP state in the BRAS until the
subscriber is okay, is a big advantage to the subscriber 
bring up rate.
 
The DHCP authentication model proposed in the "pruss-draft" 
to me is a good suggestion for a IP DHCP authentication of
broadband subscribers, which follows the same idea as PPPoE
today, and will benefit from the optimization aready done 
in BRAS equipments.
 
How will this work with IPv4 and IPv6 ??  I will expect that
the DHC WG will be able to make sure this is a proposal which 
will make sense also for IPv6 broadband subscribers.

To me the question is not as mush between PANA, 802.1x or DHCP,
it is more about, DHCP option 82 based authentication is used
today, and working, so only in the case where ISP's start placing
the access nodes in non secure locations do a subscriber CPE
authentication make sense, and then in that case what should it be ?

DHCP option 82 authentication when access nodes are in secure
locations and DHCP authentication as proposed in the "pruss-draft"
when a need is to rely on the CPE information for 
authentication sounds like the best option to me.

As such I will like to voice the support for DHC WG to take on
this work to investigate if this is a viable solution for both
IPv4 and IPv6 solutions.

thanks,
Peter

>  
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]] 
> > Sent: 23. oktober 2007 00:37
> > To: 'Mark Townsley'
> > Cc: 'Internet Area'
> > Subject: RE: [Int-area] DCHP-based authentication for DSL?
> > 
> > > >>
> > > >> I suppose that depends on the reasons given when they 
> > received the
> > > news.
> > > >> If, for example, a rejection is sent on fundamental 
> architectural
> > > >> grounds against using DHCP for subscriber line 
> authentication and
> > > >> initiation of IP sessions,
> > > >>
> > > >
> > > > What is "subscriber line authentication" now? Option 82 
> > helps with "line
> > > > identification". And what is needed is "subscriber 
> > authentication". The
> > > two
> > > > are quite distinct things.
> > > Whether the information comes as a text string via DHCP 
> > from the DSLAM,
> > > or comes via a challenge-handshake in DHCP from the CPE, is fairly
> > > immaterial in terms of the fact that DHCP is still 
> > triggering the start
> > > of an IP session at the BRAS, an Access-Request is being 
> made to AAA
> > > based on information within the DHCP messages, an Access-Accept or
> > > Access-Reject is being received by the BRAS along with a 
> subscriber
> > > profile, IP address, etc., DHCP is then allowed to continue 
> > or not based
> > > upon the AAA response, and offers information based on the 
> > subscriber
> > > profile received from AAA. A route and filter is 
> > dynamically installed
> > > at the BRAS, and equipment between the BRAS and CPE sniff 
> > the DHCP ACK,
> > > binding the IP address (or prefix) and MAC address to 
> > better ensure that
> > > only traffic from the device involved in the DHCP exchange 
> > is allowed to
> > > send packets via the offered prefix and associated MAC into 
> > the network.
> > 
> > Sorry, this just does not explain the term "subscriber line 
> > authentication",
> > if you really meant to use such a term. 
> > 
> > Anyhow, I have few questions. 
> > - Why does the DSLF think the "line identification" is not 
> sufficient
> > anymore and they think they need a crypto-based "subscriber 
> > authentication?"
> > - Once they have a subscriber authentication, do they still 
> > need the line
> > identification?  
> > - If so, how are they planning to use these dual 
> verification schemes?
> > 
> > > So, imagine you call your SP for new service. The SP finds 
> > a wire that
> > > stretches from your DSLAM to your home, give it a name, and 
> > type it into
> > > the DSLAM. Or, they ship you a box with a username and 
> > password stored
> > > in it, and you connect it to the other end of that same wire. Or,
> > > perhaps you buy your own box and you both agree on 
> something to type
> > > into it. Maybe you are even allowed to connect two boxes to 
> > one wire. In
> > > each of these cases, a credential is being transmitted to 
> > the BRAS via
> > > DHCP and the rest of the events that follow are the same. The only
> > > fundamental difference is where the name is being stored, 
> > and whether it
> > > is being passed as clear text or not.
> > > 
> > > >> the IETF and DSLF would likely be at an
> > > >> impasse as this is the fundamental basis for TR-101 and 
> > a great deal of
> > > >> code and deployment.
> > > >>
> > > >
> > > > Is TR-101 fundamentally based on using DHCP for subscriber
> > > authentication?
> > > >
> > > TR-101 is based on the scenario I outline above. DHCP plays a very
> > > significant role. Authentication of the subscriber is certainly
> > > happening (it has too, or everyone could get service for 
> free), it's
> > > just via clear text information inserted into DHCP at a 
> point in the
> > > network that the SP perceives they can trust enough that 
> > they don't need
> > > to use a cryptographic mechanism to guard against hacking. 
> > I'm not sure
> > > that trust is always well-founded, but it is the only 
> basis for the
> > > information being sent as an option vs. a set of messages.
> > 
> > We understood by now how DSLF uses line identification via 
> > DHCP option 82.
> > If the DSL deployments still need it and want to use it after 
> > there is a
> > proper subscriber authentication mechanism, they can 
> > definitely do so. But
> > otherwise, I don't see use of a subscriber authentication 
> > scheme other than
> > making one out of DHCP causing an impasse of any kind.
> > 
> > 
> > > > As for the "great deal ..." we have yet to understand 
> > what the exact
> > > delta
> > > > is, between hacking DHCP vs using PANA. I'd appreciate if 
> > someone can
> > > > enumerate it.
> > > >
> > > Start with the outline above, and think about the 
> > differences between
> > > the two options. 
> > 
> > Configure a link-local address on the CPE, run PANA first, 
> > than run DHCP.
> > I'd appreciate if you can explain us the "great deal" part of this.
> > 
> > > Know that the opt 82 would continue to exist alongside
> > > the CPE-auth version, and that it is not a realistic option 
> > to remove it
> > > from the architecture at this stage.
> > 
> > You don't have to remove it just because you are using PANA. 
> > You can keep
> > using it if you think it is necessary even after there is a proper
> > subscriber authentication used by the network.
> > 
> > Alper
> > 
> > 
> > > 
> > > - Mark
> > > > Alper
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >> - Mark
> > > >>
> > > >>> I'm sure the DSLF would appreciate the feedback and 
> > would be willing
> > > to
> > > >>> reconsider it. Besides, that's the spirit of the thread 
> > Jari started.
> > > >>>
> > > >> This
> > > >>
> > > >>> is not a 'how we merge the two documents and make an 
> > RFC out of it'
> > > >>> discussion.
> > > >>>
> > > >>> Alper
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Ralph Droms [mailto:[email-masked]]
> > > >>>> Sent: Friday, October 19, 2007 4:27 PM
> > > >>>> To: Alper Yegin
> > > >>>> Cc: Internet Area
> > > >>>> Subject: Re: [Int-area] DCHP-based authentication for DSL?
> > > >>>>
> > > >>>> Alper - It looks like the DSLF requirements have 
> > evolved over time.
> > > >>>> The initial DSLF liaison statements (May, 2007), sent 
> > to both the
> > > >>>> IETF and the IEEE, request a solution to subscriber 
> > authentication
> > > >>>> without specifying a particular solution technology.  The
> > > >>>> requirements in "Subscriber Authentication in DSL 
> > Networks" don't
> > > >>>> mention the use of any specific IETF or IEEE protocols:
> > > >>>>
> > > >>>>    Subscriber Authentication in DSL Networks
> > > >>>>    https://datatracker.ietf.org/documents/LIAISON/file457.doc
> > > >>>>
> > > >>>>    DSL Forum Liaison to IETF Internet Area about WT146
> > > >>>>    https://datatracker.ietf.org/documents/LIAISON/file458.doc
> > > >>>>
> > > >>>> The more recent DSLF liaison statement (August, 2007), 
> > sent to the
> > > >>>> IETF, is more specific, asking the IETF to adopt a 
> > document merging
> > > >>>> the mechanisms in draft-pruss-dhcp-auth-dsl-01.txt or 
> > draft-zhao-dhc-
> > > >>>> user-authentication-02 as a work item; note the title 
> > explicitly
> > > >>>> calls out DHCP:
> > > >>>>
> > > >>>>    DSL Subscriber Authentication using DHCP
> > > >>>>    https://datatracker.ietf.org/documents/LIAISON/file490.doc
> > > >>>>
> > > >>>> Therefore, it seems that now the DSLF is looking for a 
> > DHCP-based
> > > >>>> solution, based on the as yet unpublished document 
> > derived from the
> > > >>>> two I-Ds cited above.
> > > >>>>
> > > >>>> - Ralph
> > > >>>>
> > > >>>>
> > > >>>> On Oct 19, 2007, at Oct 19, 2007,4:31 AM, Alper Yegin wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> Ric,
> > > >>>>>
> > > >>>>> We are not saying DSLF MUST use PANA. But if DSLF is 
> > coming to IETF
> > > >>>>> with the
> > > >>>>> requirements it did and seeking a L3-based access 
> > authentication
> > > >>>>> protocol,
> > > >>>>> IETF has designed PANA exactly for that.
> > > >>>>>
> > > >>>>> If DSLF is satisfied with a 802.1X extension and IEEE 
> > is delivering
> > > >>>>> that, so
> > > >>>>> be it. There is nothing wrong with that.
> > > >>>>>
> > > >>>>> There does not appear to be a strong justification to 
> > hack DHCP the
> > > >>>>> way you
> > > >>>>> are proposing. Many people spoke against that already.
> > > >>>>>
> > > >>>>> Based on a cost/benefit analysis, doing that to DHCP may be
> > > >>>>> justified for a
> > > >>>>> DSL product line group, I'd understand. But not for 
> > the IETF, imo.
> > > >>>>>
> > > >>>>>
> > > >>>>> Alper
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: Richard Pruss [mailto:[email-masked]]
> > > >>>>>> Sent: Friday, October 19, 2007 6:01 AM
> > > >>>>>> To: Yoshihiro Ohba
> > > >>>>>> Cc: Internet Area
> > > >>>>>> Subject: Re: [Int-area] DCHP-based authentication for DSL?
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Yoshihiro Ohba wrote, around 19/10/07 11:39 AM:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> Option 82 makes no difference if option 82 is also
> > > >>>>>>> inserted in PANA message.  DHCP state transisions 
> (excluding
> > > >>>>>>> those for
> > > >>>>>>> EAP state transitions) before completion of 
> > authentication makes
> > > no
> > > >>>>>>> diffirence.  The only difference would be DHCP 
> > state transitions
> > > >>>>>>> after
> > > >>>>>>> successful authentication in PANA, but I don't 
> > really think this
> > > >>>>>>> is a
> > > >>>>>>> big deal that can justify significant change to DHCP.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>> You still arguing PANA? The difference is that DHCP 
> > snooping and
> > > >>>>>> Option
> > > >>>>>> 82 insertion is implemented.
> > > >>>>>> Running code, get it? DHCP snooping and Option 82 
> > insertion is
> > > >>>>>> implemented and deployed worldwide, working for millions of
> > > >>>>>> subscribers...
> > > >>>>>>
> > > >>>>>> If the DSLForum is going to try recommend the huge 
> cost to do
> > > >>>>>> something
> > > >>>>>> that changes every device in the Ethernet layer I 
> > suspect they
> > > >>>>>> probably
> > > >>>>>> will take something from IEEE,
> > > >>>>>> that fixes MAC security and takes something like 
> > 802.1x but that
> > > >>>>>> traverses client side and provider switches. Not PANA.
> > > >>>>>>
> > > >>>>>> DHCP Authentication is a small change to the 
> > existing deployment
> > > that
> > > >>>>>> has Port as credentials for Option 82 and simply 
> > adds the ability
> > > to
> > > >>>>>> have client supplied credentials but
> > > >>>>>> otherwise uses the same architecture that is 
> > deployed today for
> > > >>>>>> Option
> > > >>>>>> 82 driven Ethernet DSLAMs and the upstream 
> > terminating BRASes.
> > > >>>>>>
> > > >>>>>> - Ric
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> Yoshihiro Ohba
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> Int-area mailing list
> > > >>>>>> [email-masked]
> > > >>>>>> https://www1.ietf.org/mailman/listinfo/int-area
> > > >>>>>>
> > > >>>>>>
> > > >>>>> _______________________________________________
> > > >>>>> Int-area mailing list
> > > >>>>> [email-masked]
> > > >>>>> https://www1.ietf.org/mailman/listinfo/int-area
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Int-area mailing list
> > > >>> [email-masked]
> > > >>> https://www1.ietf.org/mailman/listinfo/int-area
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > >
> > 
> > 
> > 
> > _______________________________________________
> > Int-area mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/int-area
> > 
> 

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Stig Venaas <[email-masked]>
Date: Wed, 24 Oct 2007 11:23:50 +0200

Peter Arberg wrote:
[...]
> authentication sounds like the best option to me.

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.

DHCP is a fairly complicated protocol and we should be very cautious
making changes to the protocol itself. Changes might also require DHCP
snooping devices to be changed. If DHCP is not changed, then I think
PANA would be a more future proof solution. Of course I don't know
what other changes would be needed to make PANA work.

Stig

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Oct 2007 06:36:45 +1000

> or credentials you like without major changes to DHCP. While with say
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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Oct 2007 16:54:29 -0400

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 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.
>
> 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
>
>
>
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Oct 2007 17:03:01 -0400

Sorry, I made a goof.  Relay agents can forward fragmented DHCP  
messages.  There is, if I recall correctly, a recommendation against  
fragmentation (perhaps RFC 2131); however, the stack on the node  
where the relay agent is instantiated will re-assemble the DHCP  
message before delivering it to the relay agent, and then re-fragment  
the new DHCP message resent by the relay agent.

- Ralph

On Oct 24, 2007, at Oct 24, 2007,4:54 PM, Ralph Droms wrote:

> Section 6.3 of draft-pruss-dhcp-auth-dsl-01 addresses how to fit  
> the EAP info into DHCP options, using RFC 3396.
>
> 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
>
>> size issue of EAP in some detail, it is not clear if you are  
>> saying the proposed mechanism would not work.
>>
>> 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
>>
>>
>>
>>

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Oct 2007 07:09:09 +1000

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:
>> 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
>>
>>
>>
>>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 24 Oct 2007 23:28:34 +0200

Ralph Droms wrote:
> 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.

Yes. See also below regarding RADIUS vs DHCP

>> RADIUS (<253 bytes). While DHCP has similar problems (<255 bytes), and 
>> one could can expect that most networking companies would have 

When doing EAP with RADIUS you can transport large EAP messages by
fragmenting the EAP message and doing a series of requests and responses
fetching the fragments one by one. How would you do this with DHCP? With
RADIUS you can do e.g. EAP-TLS with EAP messages that are several
Kbytes large. I don't see how to do that with DHCP. Of course there are
other EAP mechanisms with much smaller messages that might be
sufficient.

Stig

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Oct 2007 17:36:56 -0400

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.
>
> 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
>
>> 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
>>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Oct 2007 17:41:28 -0400

One final clarification...L2-only devices might, I suppose, have  
trouble snooping fragmented DHCP messages.

- Ralph

On Oct 24, 2007, at Oct 24, 2007,5:03 PM, Ralph Droms wrote:

> messages.  There is, if I recall correctly, a recommendation  
> against fragmentation (perhaps RFC 2131); however, the stack on the  
> node where the relay agent is instantiated will re-assemble the  
> DHCP message before delivering it to the relay agent, and then re- 
> fragment the new DHCP message resent by the relay agent.
>
> - Ralph
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2007 17:40:30 -0400

> RADIUS out of DHCP, and DHCP messages should be normally sized to the 

This is too complex.  It's much simpler to run EAP and DHCP in
separate protocols.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Oct 2007 07:42:15 +1000

> other EAP mechanisms with much smaller messages that might be
Section 5.2 is probably not clear enough in the current draft but the 
DHCPEAP messages can carry request/response for as many times as you 
need until EAP success or failure.

Regards,
Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2007 17:40:30 -0400

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Oct 2007 07:42:15 +1000

Regards,
Ric

---

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Oct 2007 09:33:45 +0200

> RADIUS out of DHCP, and DHCP messages should be normally sized to the

  RADIUS packets are maximum 4k in size, so RADIUS wouldn't be the
limiting factor.  What is the limiting factor is EAPoL, where packets
can't be fragmented.  Most RADIUS servers already look for a MTU in the
Access-Request, and limit the size of EAP responses on their end, so
that the EAP data will fit into one Ethernet packet.

  My tests on various implementations show that RADIUS servers and
802.1x supplicants appear to work with MTUs set very low, such as 100
octets.  The result is a LOT more RADIUS traffic than normal, but the
authentication process succeeds.

  So limiting the DHCP packet sizes to 500 octets shouldn't affect the
operation EAP.  Similar issues apply to PANA, where there is IP and UDP
overhead on top of what would otherwise be EAPoL.

  Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 Oct 2007 11:31:27 +0300

> Similar issues apply to PANA, where there is IP and UDP

Actually such issues don't apply to PANA. PANA can utilize IP fragmentation,
hence it can carry (64K - overhead) bytes of EAP payloads.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Oct 2007 10:29:21 -0400

DHCP MTU can still be an issue.

- EAP minimum MTU is 1020 octets.

- Some EAP methods (e.g., EAP-AKA) may not work with a lower layer
where the MTU is less than EAP minimum MTU.

It seems that your tests are based on an EAP method that supports
fragmentation?

Yoshihiro Ohba

On Thu, Oct 25, 2007 at 09:33:45AM +0200, Alan DeKok wrote:
>   So limiting the DHCP packet sizes to 500 octets wshouldn't affect the

---

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Oct 2007 16:41:26 +0200

> where the MTU is less than EAP minimum MTU.

  That is likely, yes.

> It seems that your tests are based on an EAP method that supports

  Yes.  Some TLS-based methods (EAP-TLS, EAP-TTLS, and PEAP) appear to
be fine with small fragments.

  Don't take this test for more than what it is: a quick check of common
implementations.  It should not be construed as being definitive, or of
being standards compliant, or of working outside of a controlled test
environment.

  Alan DeKok.

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 12:41:37 -0700

The problem is that some EAP methods (e.g. most non-TLS based methods) don't 
support fragmentation, so in practice I'm not sure that all existing methods 
would work over a 500 octet MTU.

--------------------------------------------------
From: "Alan DeKok" <[email-masked]>
Sent: Thursday, October 25, 2007 12:33 AM
To: <[email-masked]>
Cc: "Internet Area" <[email-masked]>
Subject: Re: [Int-area] DCHP-based authentication for DSL?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Oct 2007 20:28:24 -0400

Isn't DHCP designed based on the same assumption as BOOTP in terms of
IP fragmentation?  BOOTP assumes that BOOTP messages are never
fragmented according RFC 951.

An issue with fragmenting DHCP message I can think of is that a DHCP
relay agent or server may not be able to correctly reassemble
fragmented messages when simultaneously received from multiple DHCP
clients if the source address of those messages is unspecified
(0.0.0.0).  How does DHCP address this issue?

Note: DHCPv6 does not have this issue because a specified address is
always used.

Yoshihiro Ohba

---

From: Ralph Droms <[email-masked]>
Date: Sun, 28 Oct 2007 16:22:27 -0400

The only reference to fragmentation in RFC 951 is:

3. Packet Format

    [...] For
    simplicity it is assumed that the BOOTP packet is never fragmented.

There are no references to fragmentation in RFC 213[12] or RFC 3315.

In my opinion, this reference is to simplicity in the IP layer, not  
in the BOOTP layer.  The IP layer handles any fragmentation and the  
BOOTP/DHCP layers are unaware of that fragmentation.  Therefore, any  
addresses included in the DHCP messages are irrelevant to BOOTP/DHCP  
message reassembly.

On the other hand, as I wrote in a previous message, all bets are off  
regarding L2 (or other) devices that snoop the DHCP messages without  
performing IP reassembly.

And, as a practical matter, I suspect all extant DHCP clients and  
servers have a DHCP message MTU less than 1500 octets.

- Ralph

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Oct 2007 08:16:36 +0100

Ralph Droms wrote:
> In my opinion, this reference is to simplicity in the IP layer, not in 
> the BOOTP layer.  The IP layer handles any fragmentation and the 

The issue with some (most?) client implementations, at least on UNIX, is
that they use methods like raw sockets to be able to send and receive
UDP without having an IP address. This means that the DHCP client would
need to take care of fragmentation and reassembly, and I believe they
generally don't.

Note that I haven't studied the source code of that many
implementations, but I believe this is common.

Stig

[...]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Oct 2007 07:42:35 -0400

> addresses included in the DHCP messages are irrelevant to BOOTP/DHCP  

I don't think IP layer can correctly reassemble IP datagrams with the
unspecified source address (0.0.0.0) which breaks uniqueness of
fragments among multiple *different* source nodes.

> performing IP reassembly.

Sure, this is another issue.

> servers have a DHCP message MTU less than 1500 octets.

For the above reasons, DHCP message should not be IP-fragmented.
However, DHCP message MTU being not more than link-layer MTU can be a
non-workable requirement when carrying EAP, considering the fact that
EAP can consume up to 1020 octets and additionally other options need
to be carried in a DHCP message.

Yoshihiro Ohba

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Oct 2007 09:19:53 -0700

If I understand the situation correctly (fragmentation
needed with packets having 0.0.0.0 source address), a
potential mitigation is through the use of IP-in-IP
encapsulation and RFC3927 link local addresses. A
DHCP/EAP client which does not yet have an address can
then wrap its DHCP messages in an inner IP header with
an RFC3927 source address and an outer IP header with
a source address of 0.0.0.0. Both the inner and outer
destination address would be that of the DHCP/EAP
server.

During the encapsulation, the client can fragment the
inner DHCP message into inner IP fragments no larger
than the path MTU minus 20 bytes, then encapsulate each
inner fragment in an outer IP header with DF=1.

In this sense, the RFC3927 address is still a link-local,
because the tunnel between the client and the server is
just an ordinary link from IP's perspective. There is a
potential for collision in the server's reassembly cache
with other clients choosing the same link-local address,
however the inner ip-id can be used for further
differentiation. In the event of collision in both the
ip-src and ip-id planes, the UDP checksum is available
to detect reassembly corruption and the sprite-mtu
checksum (draft-templin-inetmtu-05) could also be used
if an additional and complementary check is desired.

Or, maybe I am misunderstanding the situation?

Fred
[email-masked] 

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Monday, October 29, 2007 4:43 AM
> To: Ralph Droms
> Cc: Internet Area
> > >>>>>or credentials you like without major changes to DHCP. 
> While with
> > >>>>>say
> > >>>>>PANA you could do that.
> > >>>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Oct 2007 14:35:19 -0400

This is an interesting workaround.  However, if EAP/DHCP requires a
temporal IP address and IP-in-IP encapsulation to operate, it would be
very difficult for DSLF to claim that DHCP authentication is simple.

Yoshihiro Ohba

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 30 Oct 2007 20:10:34 +0100

> very difficult for DSLF to claim that DHCP authentication is simple.

Or in any way backward compatible.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Oct 2007 13:35:27 -0700

> very difficult for DSLF to claim that DHCP authentication is simple.

It's just a proposal, and I haven't studied the problem
(if there is one) in detail. But, I don't agree wrt the
simplicity aspect.

Fred

> > > > >>>>>It's not as simple as just putting credentials 
> into option 82
> > > > >>>>>though.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Oct 2007 13:37:02 -0700

> Or in any way backward compatible.

Well, for this to work both the client and server
need to understand the protocol - right?

Fred

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Oct 2007 18:05:26 -0400

> (if there is one) in detail. But, I don't agree wrt the

- An additional mechanism would be needed for DHCP client and DHCP
relay/server to know the IP-in-IP capability as well as 
the tunnel endpoint address of the peer.

- Use of IP-in-IP with IPv4 Link-Local address for DHCP would
introduce not only potential for collision in the server/relay's
reassembly cache, but a requirement for DHCP server/relay to maintain
mapping between hardware address and IPv4 L-L address of DHCP client,
because hardware address is no more sufficient to deliver DHCP message
to DHCP client.  These issues would affect the following requirement
in RFC 3927 on IPv4 L-L address: "A host MUST NOT alter its behavior
and use of other protocols such as DHCP because the host has assigned
an IPv4 Link-Local address to an interface."

- DHCP over IP-in-IP does not address the issue on L2 devices
requiring reaassembly of fragmented IP datagarams to do DHCP snooping.

Yoshihiro Ohba

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Oct 2007 15:40:06 -0700

At the risk of further diversion on what may/may-not be

> the tunnel endpoint address of the peer.

I was thinking that IP-in-IP would be used IFF messages
that support authentication are used. So, the use of the
authentication messages implies the use of IP-in-IP encaps.

> reassembly cache,

But, much less so than for the unspecified source address.
and any collisions would be detected by udp checksums and
dropped. Result is that client simply retries.   

> but a requirement for DHCP server/relay to maintain
> to DHCP client. 

I'm not entirely sure this is true, and if it were I don't
necessarily see a problem; the server could just echo the
LL in 'yiaddr'.

> These issues would affect the following requirement

There are two interfaces in question: 1) the interface
connected to the physical link over which the client is
attempting to configure a global address,  and 2) the
virtual interface used for IP-in-IP encapsulation. The
RFC3927 address would be assigned to interface #2; not
interface #1. By my read of the RFC3927 text you quoted,
the concern is specific to the case of both LL and global
being assigned to the same interface; not different ones. 

> requiring reaassembly of fragmented IP datagarams to do DHCP snooping.

This is outside of my expertise, but how is the situation
any different for any protocol that is subject to IP
fragmentation?

Fred
 
> > > > > > >>>>>For one thing there are strict limits on the 
> size of DHCP
> > > > > > >>>>>messages that
> > > > > > >>>>>MTU is too small for the EAP message, you need 
> multiple  
> > > > > > >>>>>requests and
> > > > > > >>>>>major DHCP changes. Hence you are not free to 
> use what EAP
> > > > > > >>>>>mechanisms

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Oct 2007 07:44:24 -0400

> authentication messages implies the use of IP-in-IP encaps.

In that case, how the DHCP client can know that authentication
messages needs to be used?

> dropped. Result is that client simply retries.   

I think that a collision must not happen.  If not, it's not the right
approach, IMO.

> necessarily see a problem; the server could just echo the

I don't think DHCP server is supposed to include in 'yiaddr' an
address that is not allocated by the server

> being assigned to the same interface; not different ones. 

I am not sure if I understand your comment.  Isn't RFC3927 address
assigned to the physical interface?

Yoshihiro Ohba

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 Oct 2007 08:16:54 -0700

Perhaps a simpler way to express the IP-in-IP encapsulation
proposal would be: "authenticate over the tunnel interface,
then configure over the physical interface". IP-in-IP
encapsulation to solve a fragmentation/reassembly issue:
how's *that* for irony?!

But, let's put that proposal aside for now and look at a
different approach. Let us define a new DHCP option called
the "DHCP fragment option" which has the following format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Code     |     Length    |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where "Flags" and "Fragment Offset" have exactly the same
format and useage as for RFC791 IP fragmentation except
that the fragmentation occurs at the DHCP level; not IP. We
say that this option must occur as the first option in the
options field of each DHCP packet, and that multiple DHCP
packets with the same xid are sent when there are multiple
fragments (the xid also serving as an identification for
reassembly).

Each fragment except the final fragment would have length=2.
The final fragment would have length=4 and would include a
16-bit checksum immediately following the Fragment Offset
field. The checksum would include a 16-bit Fletcher checksum
calculation over the DHCP packet before fragmentation
(details as to which fields are covered by the checksum to
be specified later). Or, maybe we should use the sprite-mtu
checksum (draft-templin-inetmtu) instead. Come to think of
it, we probably don't even need the "Flags" field and can
use all 16 bits for the fragment offset - but, I think you
get the big picture of where I'm going with this...

Thanks - Fred
[email-masked]

> Sent: Wednesday, October 31, 2007 4:44 AM
> To: Templin, Fred L
> Cc: Yoshihiro Ohba; Ralph Droms; Internet Area