Thanks, Mark...
- Ralph
On Oct 10, 2007, at Oct 10, 2007,11:11 PM, Mark Townsley wrote:
Ralph Droms wrote:
I believe the DSLF document "Subscriber Sessions" (DSLF WT-146)
lists the DSLF requirements for subscriber session management. Do
we (IETF) have access to this document?
Ralph, the IETF did get a liaison from the DSLF on WT-146, but the
entire document does not seem to be posted on our liaison
statements page. I'm checking with the DSLF now to see if it was
expected and understood that a snapshot of WT-146 be posted
publicly. Generally, "Working Texts" are only available to DSL
Forum members, though approved "Technical Reports" are made public.
In any case, a subsequent liaison directly included some relevant
requirements as an excerpt from WT-146, I've cut and paste them
here so that folks do not have to deal with the .doc if they don't
want to:
Req # Description
IPAuth-1 Authentication must not depend on the use of any given
application, eg web browser.
IPAuth-2 Must re-use existing SP Authentication infrastructure
(use Radius Database) and allow mixed mode operation (eg PPP and
IP) on the same L3 edge device
IPAuth-3 Must offer L3 edge device (BRAS) subscriber policy
enforcement via pull and push methods, ie L3 edge must be aware of
authentication status and any subscriber credentials
IPAuth-4 Must allow for authorization purposes the use of any
additional identifiers that may be available, eg MAC address,
Option82 circuit-id.
IPAuth-5 Should allow for subscriber nomadicity and support
tracking of changes to location.
IPAuth-6 Must fit into TR-101 operational model
(TR101 may be found here: https://datatracker.ietf.org/documents/
LIAISON/file468.pdf)
IPAuth-7 Must support revoking authentication
IPAuth-8 Must handle L3 CPE device authentication and end-device
(PC) user based authentication (likely with L2 CPEs in the latter
case)
IPAuth-9 Should be simple to implement on client (PC or CPE)
IPAuth-10 Must be independent of medium type (eg Fixed Ethernet,
Legacy ATM, PON, WiFi, WiMax, etc)
IPAuth-11 Must not require major re-work for IPv6. None ideally.
IPAuth-12 Must be resilient to attacks on the subscriber, eg
against brute-force challenge attacks, or spoofing of an
authenticator edge device
IPAuth-13 Must offer authenticator edge device resiliency, eg
not be prone to DOS authentication attacks
IPAuth-14 Must allow for authentication and download of
subscriber service profile before service IP address is assigned
IPAuth-15 Must offer an option to re-authenticate periodically
or on demand.
IPAuth-16 At an absolute minimum, must provide equivalent or
better security than PPP CHAP/MD5 does today. Must include the
ability to move to more secure authentication methods over time.
IPAuth-17 Should offer authentication fail/success reason
message to subscriber from authenticator .
IPAuth-18 Must allow for multiple authenticated subscribers on
same physical or logical interface.
IPAuth-19 Must offer scalable subscriber management, eg not
rely on subscriber credentials configured on the authenticator Edge
IPAuth-20 Must have a logical path towards standardization
IPAuth-21 Must scale to 10000s of subscribers per L3 edge
device (ie must be conservative in use of resources)
- Ralph
On Oct 10, 2007, at Oct 10, 2007,7:47 AM, Iljitsch van Beijnum wrote:
On 10-okt-2007, at 12:49, Jari Arkko wrote:
Since we are talking about converting PPPoE customers to this
new scheme, *something* at the home site has to change.
My guess would be that most likely change would be at the
DSL box that you get from the provider. If it does 802.1X,
PANA, or DHCP Auth from that point to the network does
not matter from the home user's perspective.
Today, you can:
1. hook up a PC directly to a DSL modem
2. use some kind of gateway to connect multiple PCs
3. use a modem with gateway functionality
I would be very interested in learning which of these models the
DSL forum wants to support. I'm somewhat worried about a
situation where 3. is the only option, because that way, end-
users would have to live with whatever functionality the (ISP-
provided) gateway delivers, which will invariably include NAT,
and although NAT is always a bad thing in theory, a "good" NAT
isn't too troublesome in practice while a bad one is a disaster.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
