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

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 01 Nov 2007 06:56:29 -0800

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

Also, not all EAP methods support fragmentation, and among those that do, 
not all implementations support an MTU that varies on a per-packet basis.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 1 Nov 2007 11:09:18 -0400

Defining a DHCP option that spans multiple DHCP messages for
DHCP-layer fragmentation seems to be another significant change to
DHCP.  This is not just a matter of how to handle the proposed DHCP
option but it can affect the basic DHCP message processing rule in
which only one DHCP message is generated in response to one DHCP
message.

Yoshihiro Ohba

On Wed, Oct 31, 2007 at 08:16:54AM -0700, Templin, Fred L wrote:
> 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]
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[email-masked]] 
> > Sent: Wednesday, October 31, 2007 4:44 AM
> > To: Templin, Fred L
> > Cc: Yoshihiro Ohba; Ralph Droms; Internet Area
> > Subject: Re: [Int-area] DCHP-based authentication for DSL?
> > 
> > On Tue, Oct 30, 2007 at 03:40:06PM -0700, Templin, Fred L wrote:
> > > At the risk of further diversion on what may/may-not be
> > > a problem:
> > > 
> > > > > 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.
> > > > 
> > > > - 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.
> > > 
> > > 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.
> > 
> > In that case, how the DHCP client can know that authentication
> > messages needs to be used?
> > 
> > > 
> > > > - 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, 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.   
> > 
> > I think that a collision must not happen.  If not, it's not the right
> > approach, IMO.
> > 
> > > 
> > > > 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. 
> > > 
> > > 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'.
> > 
> > I don't think DHCP server is supposed to include in 'yiaddr' an
> > address that is not allocated by the server
> > 
> > > 
> > > > 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."
> > > 
> > > 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. 
> > 
> > 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: Thu, 1 Nov 2007 09:03:43 -0700

> which only one DHCP message is generated in response to one DHCP

I'm not sure I understand the concern. The client can
tell the server that it supports DHCP fragmentation by
including a DHCP fragment option in its initial DISCOVER
even though the message is sent as a single fragment.
The server then knows that the client can accept and
reassemble fragmented DHCP messages, and can include a
DHCP fragment option in the OFFER/EAP response so that
the client can know that the server supports it too.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Nov 2007 09:46:11 -0700

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 7:56 AM
> To: [email-masked]
> Subject: RE: [Int-area] DCHP-based authentication for DSL?
> 

I don't see a problem here when DHCP fragmentation is used;
the linkMTU has no bearing on how big of a fragmented DHCP
message can be sent. How big do you want to go, i.e., is a
16bit fragment offset field enough or do you also want to
support jumbos? I guess we need to say something about the
minimum DHCP EMTU_R when DHCP fragmentation is implemented,
but again I don't see a problem. 

> not all implementations support an MTU that varies on a per-packet
basis.

Not sure what you mean about EAP methods supporting
fragmentation; DHCP does the fragmentation, and EAP
only ever sees the whole message. Do you see a problem?

Fred

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 1 Nov 2007 13:16:43 -0400

My architectural concern is that the proposal (DHCP + EAP +
DHCP-fragmentation) is towards adding more and more complexity to IP
host that is not in a fully functional state.  An IP host is not fully
functional until they have an IP address.  The fragmentation issue
comes out of this fact.  I think this proposal is just a wrong
approach to address DSL authentication issue.

Yoshihiro Ohba

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Nov 2007 10:24:48 -0700

> approach to address DSL authentication issue.

This sounds like more of a philisophical concern than
a technical one. You posed a technical issue, and I
proposed a technical solution. If there are technical
shortcomings, they should be expressed and considered
as well.

Thanks - Fred

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 1 Nov 2007 13:38:58 -0400

I am sorry, but how can I put detailed technical comments without
seeing a complete proposal?

Yoshihiro Ohba

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Nov 2007 10:46:57 -0700

> seeing a complete proposal?

Sounds like a challenge to write up a draft. I can't
make any commitments as of this moment, but I don't
see a draft as saying much more/different than what
has been said already; maybe just cut-and-paste emails?

Fred

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 1 Nov 2007 14:15:20 -0400

I am sorry, but I don't think just cut-and-paste emails can convince
people for something that is against the basic philosophy or
archicture that, I believe, has been followed for a long time.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Mon, 05 Nov 2007 13:09:50 +1000

I felt some deeper analysis on fragmentation seemed necessary after 
volume of emails on the topic.

A couple of emails lay out the basics of the matter:
http://www1.ietf.org/mail-archive/web/int-area/current/msg01110.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01116.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01121.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01124.html

The facts in summary:

"For simplicity it is assumed that the BOOTP packet is never 
fragmented." - RFC 951
According to [RFC3748 <http://tools.ietf.org/html/rfc3748>], lower 
layers must provide an EAP MTU of 1020 bytes or greater.
"Also, not all EAP methods support fragmentation, and among those that 
do, not all implementations support an MTU that varies on a per-packet 
basis." - Bernard Aboba

Now this is all fine but from the thread I infer that people are making 
two additional incorrect assumptions that actually introduce a problem 
where none exists.

The first assumption is people assume the minimum DHCP message size, 
which is not reasonable or accurate for the deployments use cases at 
hand.  The link MTU here can be reasonably assumed to be at least 1500 
bytes as it is Ethernet.

Secondly people seem to assume that other DHCP options will be making 
the space available for EAP options to stack vary, thus creating a 
variable MTU for EAP.  This is not the case, the draft has an option 
which puts one-way chap onto the existing methods but for the EAP 
alternative a new DHCP message is proposed just to carry the EAP message 
option.

Thus in summary there is no fragmentation issue as DHCP Authentication 
alternative for EAP.  

- Ric

P.S. Also on a simple practical note but kind of off topic, I had a look 
at EAPOL traces for the various methods nothing and in the sample I saw 
nothing was near 500 bytes in length from the ones that do not support 
fragmentation.   The main two that are of a concern that do not support 
fragmentation today are EAP-SIM and EAP-AKA, how large do these actually 
get, in practice, I understand new messages could expact EAP-SIM but 
what is it today?

---

From: Ralph Droms <[email-masked]>
Date: Mon, 5 Nov 2007 22:06:02 -0500

For completeness, I think the fundamental potential problem (which  
Ric did not describe explicitly) arises from the observation that  
DHCP messages sent with a 0.0.0.0 source address (typ. from a client  
when the client does not have a confirmed address assignment) cannot  
be fragmented by IP (well, they can be fragmented but not reliably  
reassembled).  There is a secondary potential problem with snooping  
(rather than forwarding by a relay agent) DHCP messages that have  
been fragmented by IP.

So, if messages from DHCP clients will never exceed the MTU between  
the client and the first relay agent, the first problem won't be  
realized.  And, if none of the DHCP messages between the client and  
the relay agent exceed the MTU, the second problem won't be realized.

If I have my arithmetic correct, allowing for the DHCP message  
header, magic cookie and some option headers (you'll need one two- 
byte option header for each 254 bytes of payload), there should be  
about 1240 bytes available for authentication info payload in an  
unfragmented DHCP message on a link with a 1500 byte MTU.  I'll leave  
it to the EAP experts to determine if EAP payloads can be carried  
under these constraints.

And, of course, unlimited authentication info can be carried if DHCP  
is extended to allow that info to be spread over multiple DHCP  
message exchanges.  Not that I recommend such an extension, which the  
dhc WG ruled out early on in the development of DHCP when we realized  
such an extension would be reinventing either TFTP/UDP or TCP,  
depending on how you want to solve the problem.

- Ralph

On Nov 4, 2007, at Nov 4, 2007,10:09 PM, Richard Pruss wrote:

> According to [RFC3748], lower layers must provide an EAP MTU of  
> 1020 bytes or greater.
> "Also, not all EAP methods support fragmentation, and among those  
> that do, not all implementations support an MTU that varies on a  
> per-packet basis." - Bernard Aboba
>
> Now this is all fine but from the thread I infer that people are  
> making two additional incorrect assumptions that actually introduce  
> a problem where none exists.
>
> The first assumption is people assume the minimum DHCP message  
> size, which is not reasonable or accurate for the deployments use  
> cases at hand.  The link MTU here can be reasonably assumed to be  
> at least 1500 bytes as it is Ethernet.
>
> Secondly people seem to assume that other DHCP options will be  
> making the space available for EAP options to stack vary, thus  
> creating a variable MTU for EAP.  This is not the case, the draft  
> has an option which puts one-way chap onto the existing methods but  
> for the EAP alternative a new DHCP message is proposed just to  
> carry the EAP message option.
>
> Thus in summary there is no fragmentation issue as DHCP  
> Authentication alternative for EAP.
>
> - Ric
>
> P.S. Also on a simple practical note but kind of off topic, I had a  
> look at EAPOL traces for the various methods nothing and in the  
> sample I saw nothing was near 500 bytes in length from the ones  
> that do not support fragmentation.   The main two that are of a  
> concern that do not support fragmentation today are EAP-SIM and EAP- 
> AKA, how large do these actually get, in practice, I understand new  
> messages could expact EAP-SIM but what is it today?
>
>
>
>
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Nov 2007 09:03:31 -0800

Ralph, 

> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Monday, November 05, 2007 7:06 PM
> To: Internet Area

Right about the IP fragmentation issues; that is why it
may be worth considering DHCP fragmentation. As Ric said,
fragmentation may be a non-issue for specific use cases
(e.g., the one that inspired the DHCP auth proposal) but
if we wanted to extend to other use cases there may be
instances in which path MTU restrictions play a role.

One use case for consideration is Mobile Ad-hoc Networks.

Fred