Subject: RE: [Int-area] Combined draft on DHCP authentication

From: "Alper Yegin" <[email-masked]>
Date: Sun, 2 Dec 2007 00:15:18 +0200

Your latest I-D says:

   Further, **different devices in the home** may have different policies 
   and require different credentials.  

and 

      The DHCP Client resides either on a **home network device** or the 
      HGW, and the DHCP Server protocol state machine may reside fully on 
      the NAS.

Obviously neither the DSLF requirements nor your I-D mean to leave PCs at
home out of scope.

Alper

> -----Original Message-----
> From: Richard Pruss [mailto:[email-masked]]
> Sent: Thursday, November 22, 2007 10:41 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Int-area] Combined draft on DHCP authentication
> 
> Alper possibly this has been the problem with this thread.  You simply
> do not understand that half the complexity in the DSL deployment is the
> Layer 2 parts of TR-101.
> 
> - Ric
> 
> 
> Alper Yegin wrote, around 22/11/07 7:16 PM:
> >
> > There is no point in getting lost in the TR-101 text.
> > You said to look at the requirements, so we did it.
> > It reads in plain English:
> >
> > 	Should be simple to implement on client (PC or CPE)
> >
> > Unless PC is not "PC", there is no point in arguing....
> >
> >
> >> -----Original Message-----
> >> From: Richard Pruss [mailto:[email-masked]]
> >> Sent: Thursday, November 22, 2007 10:53 AM
> >> To: Yoshihiro Ohba
> >> Cc: Alper Yegin; [email-masked]
> >> Subject: Re: [Int-area] Combined draft on DHCP authentication
> >>
> >>
> >>
> >> Yoshihiro Ohba wrote, around 22/11/07 2:59 PM:
> >>> Section 2 of TR-101 says:
> >>>
> >>> "The principle guiding this specification work is that the resulting
> >>> functions should enable an as smooth as possible migration process
> >>> from an ATM based aggregation network to an Ethernet based aggregation
> >>> network."
> >>>
> >>> Terminal originated PPPoE is mentioned also in TR-101 (e.g., Figure
> 15).
> >>>
> >>> >From customer's point of view, it would be natural to think that a
> >>> *smooth* migration path includes support for existing PPPoE terminals
> >>> to be able to migrate to Ethernet based aggregation network without
> >>> necessarily upgrading their legacy CPEs to RGs.
> >>>
> >>> In this thread, when the discussion comes to end-host support, I
> >>> always see inconsistency between what is stated in the DSLF
> >>> requirements (and TR-101) and what is stated by proponents of DHCP
> >>> authentication.  If IPAuth-8 and IPAuth-9 are not really requirements,
> >>> why not re-send revised requirements officially from DSLF to IETF?
> >>> Unless requirements are revised, I don't think we can make a progress.
> >> I am sorry I do not see the inconstancy, the requirements make perfect
> >> sense if you understand that the TR's have multiple deployment models
> in
> >> them.
> >>
> >> TR-101 is about moving from an ATM uplink for DSLAMs (access nodes) and
> >> TR-101 mandated no changes to the CPE or RG's.  WT-148 which we are
> >> working on now is not TR-101 and while all involved want the minimum
> >> changes it is well understood that we cannot remove PPPoA and PPPoE
> from
> >> the system without changing the CPE.
> >>
> >> The system must provide a model for supporting PC's with no change to
> >> the software of the PC is provided in TR-101 and it does not involve a
> >> credential exchange.  This system must continue to work in the new
> >> proposal and the DHCP Authentication draft has a section on handling
> >> clients that do not support the authentication mechanism.
> >>
> >> Regards,
> >> Ric
> >

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

---

From: Richard Pruss <[email-masked]>
Date: Mon, 03 Dec 2007 08:34:48 +1000

Alper, I am sorry that you are not getting this but I believe that 
adding software to PC's are specifically out of scope.  Any SP who has 
deployed something like PPPoE clients onto an end-users PC have an 
allergic reaction to adding things to customer PC's.  From that point on 
the customer counts you as responsible for every thing that happens to 
that PC.

I see this attitude in the requirement:
IPAuth-1	Authentication must not depend on the use of any given 
application, eg web browser.

These requirements will not stand up to a bunch of lawyering, they were 
a living list copied down during the course of debates in the DSLForum. 
You need to read them with some common sense and understanding of DSL 
networks and deployments.

The draft caters for devices on the home network like a set-top box or 
other service device to participate in authentication.

- Ric

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 2 Dec 2007 20:49:31 -0800

On 2 dec 2007, at 14:34, Richard Pruss wrote:

> adding software to PC's are specifically out of scope.  Any SP who  
> has deployed something like PPPoE clients onto an end-users PC have  
> an allergic reaction to adding things to customer PC's.

 From reading the stuff posted to this list I don't believe this to be  
out of scope.

What I'm afraid of is a solution that is very hard or impossible to  
deploy on common operating systems without the help from their vendor  
so a CPE device is always necessary. The problem with that is that  
with IPv4, customers typically only get a single address (I don't see  
a way for DHCP to provide multiple) so that this CPE must implement  
NAT functionality. NAT is never good, but there's a big difference  
between a reasonable NAT and a bad one. So it's extremely important  
for users to have a choice here. If service providers give customers  
CPEs that integrate the modem and NAT functions this means consumers  
are no longer in charge of their own destiny in this regard.

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 4 Dec 2007 03:59:30 +1000

>  From reading the stuff posted to this list I don't believe 

=> I agree. In fact this is done. My ISP required this, specifically for
user authentication. Of course this can also be done on the CPE.  

Hesham

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 12:02:53 -0500

On Dec 2, 2007, at 11:49 PM, Iljitsch van Beijnum wrote:
> So it's extremely important

On the other hand, if the IETF doesn't do a standard, then we're  
really hosed, because the ISPs may implement solutions for which the  
protocol is not specified in an open way.   So refusing to cooperate  
here may cause more harm than good - it would be better if we could  
find a solution that's acceptable to everyone, even if it is not one  
that everyone can love (do we ever have one of those?).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Dec 2007 12:14:38 -0800

> that everyone can love (do we ever have one of those?).

Good point.

However, making this happen with DHCP probably has a largely similar  
effect.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 16:21:39 -0500

> However, making this happen with DHCP probably has a largely similar

Making it happen with DHCP will mean that vendors who want to  
interoperate will have to implement it.   And end-users who are  
running Windows 95 will have to switch to Linux.   While I agree that  
this is an inconvenience, the Internet could do with fewer virus- 
ridden ancient Windows machines, so I'm having trouble seeing it as a  
tragedy.

For comparison, recent releases of Windows and Mac OS X do support  
PPPoE.   As does Linux.   As do most NAT boxes.   And most NAT boxes  
can be reflashed with new Linux firmware if their firmware doesn't  
support PPPoE.   So there's reason to think that in fact buying a  
custom box from the ISP will not be the end-user's only option,  
although for some it may be preferable.

Whereas if we do not have a standard, there very definitely will be no  
choice other than to purchase the ISP's custom box.   So it's  
something to think about.   Also bear in mind that it's a big win to  
get ISPs to switch away from PPPoE.   We want to help them.   Anyway,  
I do.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 4 Dec 2007 00:07:46 +0200

> really hosed, because the ISPs may implement solutions for which the

IETF has already done a standard exactly for this problem: PANA. 

What we are discussing is additionally defining another protocol, a fully
redundant one (putting aside all of its problems), just because some like
that other protocol. 

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 3 Dec 2007 18:54:35 -0500

> From: Alper Yegin, December 03, 2007 5:08 PM
> 

If PANA was the right tool to solve this problem, then I would gladly
help implement it.  For reasons already well discussed on this alias, I
see the operational complexities on the CPE as unnecessary (& possibly
prohibitive), at least for the Broadband marketplace.  

IMHO, 802.1af is the next best option to DHCP Auth for a standards based
alternative.  But 802.1af is still quite early in its process.  I am
with Ted in hoping that we don't assist in driving proprietary
alternatives in any interim. 
 
> What we are discussing is additionally defining another 
> protocol, a fully redundant one (putting aside all of its 
> problems), just because some like that other protocol. 
> 
> 
> Alper
> 
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 4 Dec 2007 02:23:36 +0200

> prohibitive), at least for the Broadband marketplace.

None of the reasons listed by the dhcp-auth supporters in fact hold water.
Anyone who reads the whole thread can see that themselves.

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 4 Dec 2007 01:42:17 +0100

Hi,

Please consider some general comments on the scope of the proposed
solution.

- Location of the DHCP client

The section 5 seems to only consider DHCP clients residing in the HGW
whereas it is indicated in section 3 "The DHCP Client resides either on
a home network device or the HGW". If both implementations are supported
by the solution, the draft should clearly documented the case of the
authentication of devices behing the HGW. If not, such
limitations/restrictions should be indicated. Such information will be
important to appraise the applicability scope of the proposed solution.
By the way, it is wothwhile to note the per-user authentication will be
required also for user devices connected to the HGW.

- Location of the DHCP server

In the section 5, NAS and DHCP server are colocated whereas it is
described that the NAS may also act as a DHCP relay agent between the
DHCP client and the DHCP server. It could be useful to see a description
of the latter implementation option, with any possible impacts (or
required enhancements) on the proposed solution.

- IPv6 Applicability

As already mentioned, there is nothing about the applicability of the
solution to an IPv6 environment. Even if not massively deployed for now,
IPv6 support is nevertheless an architectural requirement in the DSL
service model. This consequently applies also to the access
authentication solution defined for DSL networks.

- Network-initiated re-authentication

I wonder if there are EAP methods that require EAP server-intiated
re-authentication procedures. If it is the case, is it correct to say
that the DHCP protocol would not be the best candidate for such a
requirement? That wouldn't preclude the use of this solution when
server-initiated procedures are not needed. Anyway an added text
clarifying such a limitation could be useful (if needed at all). By the
way, if server-initiated re-authentication is not supported, that could
mean that there would be a need to bind the session authorization
lifetime to the DHCP lease. But there is no indication of such possible
binding in the document...

Best Regards,

Lionel