Subject: [dhcwg] draft-pruss-dhcp-auth-dsl-03

From: Richard Pruss <[email-masked]>
Date: Fri, 25 Jul 2008 08:41:44 +1000

Hi,

To help the discussion next week I was prompted to put out a summary  
of changes.
http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-03

We have tried in this version to address concerns raised in IETF 70.
Jari and Ralph's preso may remind you of those:
http://www.ietf.org/proceedings/07dec/slides/intarea-2/sld1.htm

We have added a first draft proposal for DHCPv6 messages for a limited  
set of IPv6 deployments.
http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-03#section-5.2

We now have added a DHCP relay model to the DHCP proxy/server model  
that was the document model.
(DHCP proxy is a term used in the DSL architectures, where the BRAS  
acts as a server to the client.)

We have added a section on fragmentation.
http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl-03#section-8

The DHCP EAP request response messages are now separate messages to  
possibly make the flow clearer
and hopefully make the discussion around DHCP vs EAP retransmission  
responsibility easier for people to understand.

There is a section on backwards compatibility and a number of cases  
considered, no updates to that but it addresses one of the bullets on  
the slides in IETF-70.

- Ric

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Pruss <[email-masked]>
Date: Sun, 27 Jul 2008 12:47:04 +0100

Thanks for your comments,

On 27/07/2008, at 10:19 AM, Yoshihiro Ohba wrote:

> I have a couple of comments on new dhcp-auth I-D.
>
> - It still does not seem to address the issue of the difference in
> retransmission directions.  Especially I am not sure how dhcp-auth
> works when EAP-Success/Failure gets lost.
>
> - Comment on fragmentation.  The current draft says that there is over
> 200-octet space available more than the EAP MTU of 1020 octets.
> However, I am not sure that if over 200-octet space is really
> sufficient for 1500-octet MTU considering that DHCP relay agent
> information option can be inserted by DHCP relay agent as well as
> there can be 'shim' layers below IP.

Relay's typically add only port information so I think we can be quiet  
safe with our 200 bytes
also considering the real world EAP packet sizes.

- Ric

>
>
> - DHCP EAP request response message can be more confusing, considering
> the new extension to EAP such as ERX (draft-ietf-hokey-erx) where two
> new messages are defined that are neither request nor response.
> Considering ERX, I would strongly discourage combining DHCP and EAP
> because ERX can make integration of DHCP and EAP even more difficult.
> It is best if we separate IP address configuration from network access
> authentication.
>
> Regards,
> Yoshihiro Ohba
>
> On Fri, Jul 25, 2008 at 08:41:44AM +1000, Richard Pruss wrote:
>> Hi,
>>
>> To help the discussion next week I was prompted to put out a  
>> summary of
>> changes.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Mon, 28 Jul 2008 01:06:11 -0400

I agree with what Yoshihiro has pointed out, in that there is no way to
indicate how a EAP Failure would be indicated to the client in
DHCP_Auth.

Similarly, im a little bit worried here about how we would use DHCP_Auth
to authenticate individual IP Sessions behind the same subscriber line? 

Alan K 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Pruss
Sent: July 27, 2008 7:47 AM
To: Yoshihiro Ohba
Cc: [email-masked]
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-03

Relay's typically add only port information so I think we can be quiet
safe with our 200 bytes also considering the real world EAP packet
sizes.

- Ric

>> We have added a first draft proposal for DHCPv6 messages for a 
>> limited set of IPv6 deployments.
>> possibly make the flow clearer and hopefully make the discussion 
>> around DHCP vs EAP retransmission responsibility easier for people to

>> understand.

---

From: Richard Pruss <[email-masked]>
Date: Mon, 28 Jul 2008 10:26:36 +0100

I certainly  would be concerned with trying to drive deployed DSL  
Forum architectures to somehow authentication sessions behind the  
residential gateway, with a bridge it is all simple, but when you have  
a gateway with NAT then things become complicated.

In DSL we have no equivalent of the tight coupled Media Access Control  
layer in the cable model in the RG. So whenever the home network  
becomes part of the authentication discussion and ideas start to take  
flight about coupling ALG's in NAT with authentication in the RG, I  
run a mile.

- Ric

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Jul 2008 09:28:27 -0700

I haven't touched 'draft-templin-dhcpmtu' since the
last time this subject came up, but AFAICT it will
still work fine even if relay agent information
options are inserted.

Per RFC3046:

   "A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last option (but before 'End Option' 255, if present) in
   the DHCP options field of any recognized BOOTP or DHCP packet
   forwarded from a client to a server."

So, as long as 'draft-templin-dhcpmtu' is updated to
say that the reassembly process ignores any relay agent
information options the DHCP fragmentation/reassembly
will still work fine. 

Ric is right that the normal-case link MTU is 1500 bytes,
but there is a remote possibility of smaller link MTUs
and/or larger DHCP messages; draft-templin-dhcpmtu'
addresses both possibilities. The approach would be
for the DHCP AUTH client to try w/o fragmentation first,
then try again using fragmentation if the unfragmented
attempt fails.

Fred
[email-masked] 

>From: Richard Pruss [mailto:[email-masked]] 
>Sent: Sunday, July 27, 2008 4:47 AM
>To: Yoshihiro Ohba
>Cc: [email-masked]

---

From: "Alan Kavanagh" <[email-masked]>
Date: Mon, 28 Jul 2008 19:39:58 -0400

Hmm, im not quite sure on this.

To me, a subscriber being attached to a Physical DSL Line would need to
have the possibility to authenticate just this subscriber for a given IP
Service, this is not tied to NAT or ALG in any way. 

I agree Richard that for a bridged RGw this is not an issue since the
individual subscriber must be authenticated in this case, but for this
to work, DHCP_Auth is "Required to be supported by the clients"....and
this to me is a burden on the clients, is this something we want to push
Richard? This is what im asking. Now this is also similar in the "Routed
RGw" case, i dont just want to have line authentication, i "need per
subscriber authentication" and looking at the current draft we perhaps
need to put some additional use cases to handle these noted above, would
you agree?

BR
Alan K

-----Original Message-----
From: Richard Pruss [mailto:[email-masked]] 
Sent: July 28, 2008 5:27 AM
To: Alan Kavanagh
Cc: Yoshihiro Ohba; [email-masked]
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-03

I certainly  would be concerned with trying to drive deployed DSL Forum
architectures to somehow authentication sessions behind the residential
gateway, with a bridge it is all simple, but when you have a gateway
with NAT then things become complicated.

In DSL we have no equivalent of the tight coupled Media Access Control
layer in the cable model in the RG. So whenever the home network becomes
part of the authentication discussion and ideas start to take flight
about coupling ALG's in NAT with authentication in the RG, I run a mile.

- Ric

On 28/07/2008, at 6:06 AM, Alan Kavanagh wrote:

> I agree with what Yoshihiro has pointed out, in that there is no way 
> to indicate how a EAP Failure would be indicated to the client in 
> DHCP_Auth.
>
> Similarly, im a little bit worried here about how we would use 
> DHCP_Auth to authenticate individual IP Sessions behind the same 
> subscriber line?
>
> Alan K
>

---

From: Richard Pruss <[email-masked]>
Date: Tue, 29 Jul 2008 09:31:49 +0100

Hi Alan,

I agree with you that we need add use cases to the base architecture  
for this.

Possibly a place to start is clarify in the service definitions that  
we have cases that have
separate administrative domains servicing the bridge RG case.   
Addressing design seems key
as this will dictate to whom we address the authentication requests.  
Once we know whom is supplying
the addresses and it clears up who would want to authenticate.

A key factor to consider here is of architecture difference between   
the US & Asia-Pac providers and as opposed to the European providers  
due to regulatory requirements for wholesale.

- Ric

On 29/07/2008, at 12:39 AM, Alan Kavanagh wrote:

> Forum
> becomes
>>>> summary

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Jul 2008 07:55:28 -0700

>From: Yoshihiro Ohba [mailto:[email-masked]] 
>Sent: Tuesday, July 29, 2008 6:24 AM
>To: Templin, Fred L
>Cc: Richard Pruss; [email-masked]
>On Mon, Jul 28, 2008 at 09:28:27AM -0700, Templin, Fred L wrote:
>One issue with 'draft-templin-dhcpmtu' is that essentially there is a
>possibility of collision of fragments generated by multiple DHCP
>clients using 0.0.0.0 address.  This is because IP source address, the
>'xid' field in the DHCP message header, and the Identification field
>in the DHCP fragment option are used for reassembly, and it is
>possible that multiple DHCP clients prior to address allocation happen
>to use the same set of values for them.

You are kidding, right? True, we don't have an IP source
address (the whole reason for considering this approach)
but we do have 2 32bit randomly-chosen fields. That gives
64bits of uniqueness, and the probability for collision
for two nodes selecting randomly-chosen 64bit IDs is
"vanishingly small" as analyzed in RFC4429, Appendix A.
The probability of collision is certainly negligible
when compared to that for IP fragmentation which uses
a fixed 32bit IP source address plus 16bit ip_id.

In fact, draft-templin-dhcpmtu as it stands is overkill
along several different vectors. First, the sprite-mtu
checksum is completely unnecessary when we have such
high assurance against misassociating fragments during
reassembly. Secondly, the 32bit Identification field
is overkill when we consider that we already have a
randomly-chosen 32bit xid and that ordinary use cases
would not have millions of nodes on the same link
trying to bootstrap themselves at the same time.
Also, the UDP checksum will catch most reassembly
errors if fragment misassociation somehow occurs.
Finally, how bad could it be if a reassembly error
actually slipped past the UDP checksums? The server
would get confused and discontinue processing of
the message, and the client would time out and
try again.

These factors (plus some easily-fixed errors such as
failure to observe the 255 byte length restriction
for DHCP options) seem like reason enough to revive
the draft.

Thanks - Fred