Subject: RE: [Int-area] DSL forum liaison statement on subscriberauthentication

From: "Alper Yegin" <[email-masked]>
Date: Fri, 10 Aug 2007 22:21:02 +0300

Hi Dave,

> Some of the key issues to keep in mind here are:
> 
> 1) Is the logical link point-to-point, or is it shared among multiple
> devices of the same subscriber, or is it shared among multiple
> subscribers?
> Requirement IPAuth-18 and WT-146 implies that all three are legal
> models.

According to my understanding, the architecture is intended to be capable of
identifying the data traffic of an authenticated client, and enforcing a
policy on it. This relies on network element placement, of course.

> 2) Is the problem about authenticating access to the local link, or
> about authenticating access to the network behind the L3 edge device?

I think it is both. I'm not aware of a case where clients are authorized to
send/receive IP traffic with the others connected to the same DSLAM/BRAS,
but not with the ones on the Internet. 

Alper

> There's no significant difference in the point-to-point link case, but
> in the other two models, the difference becomes very significant.  So
> for example, for subscriber-to-subscriber communication where
> subscribers are on the same shared media, do you care about restricting
> access between them?  If so, then L3 is the wrong place to solve the
> problem, and the whole notion of IP Sessions is suspect for this
> particular problem.  Indeed, the requirement would be for a
> network-layer-protocol-independent solution.  Basically you would want a
> mechanism which is L2-independent as well as L3-independent.
> 
> 3) Since power management is an important issue for many hosts, and
> there can be (per WT-146) hosts on the link, it is important to not
> constantly ping hosts with packets that can result in the host coming
> out of a low power state, as this can drastically increase the power
> costs (either in electric bill, or battery life) to consumers.  Hence
> page 17 of WT-146 can be scary to many people.
> 
> -Dave
> 
> > -----Original Message-----
> > From: Jari Arkko [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2007 2:35 PM
> > To: Internet Area
> > Cc: Dhc Chairs
> > Subject: [Int-area] DSL forum liaison statement on subscriber
> > authentication
> >
> > This relates to the earlier discussion on using DHCP or something
> > else for subscriber authentication and/or network access control.
> >
> > We have received a liaison statement from the DSL forum.
> > Please see
> >
> >   https://datatracker.ietf.org/documents/LIAISON/file457.doc
> >   https://datatracker.ietf.org/documents/LIAISON/file458.doc
> >   http://www.dslforum.org/techwork/tr/TR-101.pdf
> >   http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc
> >
> > Comments on these requirements and potential approaches
> > to satisfying them would be appreciated.
> >
> > Jari
> >
> > P.S. The last two items have been missed in the IETF liaison
> > site; I'm working to get them up there.
> >
> >
> >
> > _______________________________________________
> > 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: Dave Thaler <[email-masked]>
Date: Tue, 14 Aug 2007 12:48:45 -0700

Alper Yegin writes:
> According to my understanding, the architecture is intended to be
capable
> of

I don't see how your response above is relevant to issue #1, which is
the link model.

> I think it is both. 

If it is both, and the link is capable of carrying non-IP traffic (like
Ethernet is), then a L3 solution would be particularly inappropriate.

-Dave

> I'm not aware of a case where clients are authorized
> to

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 15 Aug 2007 23:31:08 +0300

> I don't see how your response above is relevant to issue #1, which is

I think there are a number of different models supported by the
architecture. I was trying to answer your question based on how it may
relate to access authentication. I'll let a more DSL-clueful person explain
us the link model(s).

> Ethernet is), then a L3 solution would be particularly inappropriate.

WT-146 provided by DSLF is all about "IP sessions." So, I presume non-IP
traffic is out of scope.

Alper

---

From: Dave Thaler <[email-masked]>
Date: Wed, 15 Aug 2007 14:23:52 -0700

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2007 1:31 PM
> To: Dave Thaler; 'Internet Area'
> Cc: 'Dhc Chairs'
> Subject: RE: [Int-area] DSL forum liaison statement on
> subscriberauthentication
> 
[...]
> WT-146 provided by DSLF is all about "IP sessions." So, I presume
non-IP
[...]

Yes I think that's a fundamental problem.  They're not considering the
larger issues, and as a result some are asking for a poor solution.

-Dave

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Fri, 17 Aug 2007 14:36:58 +0200

> From: Dave Thaler [mailto:[email-masked]] 
> Sent: 15 August 2007 23:24
> To: Alper Yegin; Internet Area
> Cc: Dhc Chairs
> > > > > 2) Is the problem about authenticating access to the 
> local link,
> or
> Yes I think that's a fundamental problem.  They're not 
> considering the larger issues, and as a result some are 
> asking for a poor solution.

While theretically other protocols may be possible, practically DSL
service operators support only IP traffic for residential users, and a
majority of business L3 services too. As such the solution requested for
this space is precisely for that, no more, no less.

-Woj.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Aug 2007 10:23:42 -0700

> From: Wojciech Dec (wdec) [mailto:[email-masked]]
> Sent: Friday, August 17, 2007 5:37 AM
> To: Dave Thaler; Alper Yegin; Internet Area
> Cc: Dhc Chairs
> > > > > > about authenticating access to the network behind the L3
edge
> > > > device?
> > > > >
> > > > > I think it is both.
> > > >
> > > > If it is both, and the link is capable of carrying non-IP
traffic
> > (like

I think there is some confusion here, perhaps on my part (which is why I
was asking the questions).  

Since we agree that there can be two machines of the same subscriber on
the same link, in at least one of the models supported by WT-146 and
IPAuth-18, what _prevents_ those two machines from using a protocol
other than IP?

And since we agree that there can be two subscribers on the same shared
link, in at least one of the models supported by WT-146 and IPAuth-18,
what _prevents_ those two subscribers from using a protocol other than
IP?

-Dave

---

From: Steven Blake <[email-masked]>
Date: Fri, 17 Aug 2007 21:01:53 -0400

> what _prevents_ those two subscribers from using a protocol other than

Usually because the "link" is realized with a filtering bridge, which
might be implementing mechanisms similar to the ones described in 
RFC 4562.

Regards,

// Steve

---

From: Richard Pruss <[email-masked]>
Date: Mon, 20 Aug 2007 08:39:49 +1000

Dave Thaler wrote, around 18/8/07 3:23 AM:
>>>>> Ethernet is), then a L3 solution would be particularly
>>>>>           
>>> inappropriate.
>>>       
>>>> WT-146 provided by DSLF is all about "IP sessions." So, I presume
>>>>         
>>> non-IP
>>>       
>>>> traffic is out of scope.
>>>>         
>>> [...]
>>>
>> majority of business L3 services too. As such the solution requested
>>     
> for
>   
By this you seem to be talking about two devices behind the home 
gateway, which assuming it is some Ethernet switch, they should have no 
problem talking to each other in a protocol other than IP.  It's when 
you look at service provided by the service provider on the other side 
of the home gateway when the assertion is made that the service provider 
is only providing an IP service.
> what _prevents_ those two subscribers from using a protocol other than
Well the would of the WT-146 effort is about defining the ability to 
give service at a greater than port granularity but one should remember 
that underlying the IP Session is a port to which services are bound.  
So the answer to your question is the service definition by the Service 
Provider is for an IP service explicitly and they do want to prevent 
people running random protocols over the layer 2 network.  These layer 2 
networks can be 200 K in size and you need to have security and control 
on session behaviour in networks of that size.

In short I read IPAuth-18 as saying port is part of the session 
definition.  So a session is for a Port+IP.
 
- Ric

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Mon, 20 Aug 2007 09:23:47 +0200

> considering 
> > > the larger issues, and as a result some are asking for a poor 
> > > solution.
> > 
> > While theoretically other protocols may be possible, practically DSL

> I think there is some confusion here, perhaps on my part 
> (which is why I was asking the questions).  
> 
> Since we agree that there can be two machines of the same 
> subscriber on the same link, in at least one of the models 
> supported by WT-146 and IPAuth-18, what _prevents_ those two 
> machines from using a protocol other than IP?
> 
> And since we agree that there can be two subscribers on the 
> same shared link, in at least one of the models supported by 
> WT-146 and IPAuth-18, what _prevents_ those two subscribers 
> from using a protocol other than IP?

Ah, I get you now. Guess that this deserves some more explanation. Both
of the scenarios you describe above would involve moving of traffic over
what's considered as the "home" network segment, and forwarding
restrictions are not in place on that. The subscriber line and/or DSL
CPE is the demarcation point between trusted and non-trusted network
segments, with an SP operator most often not desiring to control or
restrict traffic on the non-trusted side (where one can presumably run
IPX, Netbeui, etc). It is in the case of sending traffic to the trusted
part that the operator wants to authenticate the senders, or only one of
the senders (eg authenticate a video STB, but not a users PC device)
that connect to the operators network using an L2 CPE.

-Woj.