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
