Et Tu Brutus,
Inline:
David R Oran wrote, around 17/10/07 10:40 PM:
Jari asked me to forward this to the int-area list, so here it is:
I have similar architectural questions and concerns.
Full disclosure: I have had a long-standing (>18 month) standing
technical disagreement with the author of one of the proposals. I have
suggested a number of alternative designs, which have not been
pursued.
The state of affairs is that a number of DSL providers have awakened
to the fact that PPPoE does not scale well in G-PON environments, and
are looking to a system which maintains the PPPoE L2 virtual-circuit
model of subscriber management and security while using a
lighter-weight and scalable solution like DHCP. However, they are
allegedly unable (unwilling?) to replace the PPPoE-style authorization
scheme with something architecturally clean, and instead see adding
access authorization as a side-effect of IP address assignment as the
expedient thing to do.
In the PPPoE world, IP addresses are assigned as part of link
initialization and hence the two operations are atomic. In the world
of multi-access channels and DHCP, they two are not coupled unless you
change the DHCP protocol to make them coupled.
I think coupling IP address assignment (and by extension the rest of
host configuration) to access authorization is the wrong thing to do,
for a number of reasons:
a) The two have little or nothing to do with one another conceptually
AAA has always coupled authentication and configuration.
b) It ties access authorization to DHCP lease times, forcing
tradeoffs/compromises between address pool usage as a resource and
communication bandwidth as a resource.
Connects, does not tie. Authentication can live longer than the lease.
c) It limits, and perhaps prohibits, an IP-based approach to access
authorization via a separate protocol, thereby making a number of
things more difficult, among them are:
- the ability to provide destination address-limited or rate-limited
IP packet transport prior to access authorization, or in the case
where it fails due to reasons other than the subscriber not having
appropriate credentials.
- the ability to receive packets from a (possibly limited) set of
services that need to talk to the host prior to access authorization.
If you couple to DHCP, the host is essentially able to do nothing
useful if it can't send packets because it can't obtain an IP address.
You are assuming the outcome of a policy actions in the BRAS. If a
client does not authenticate it can be given an IP address and
appropriate network context configuration that can let the user by
example reach a web server to subscribe to the service.
- Ric
d) it makes yet another arbitrary difference between unicast and
multicast - I can receive multicasts without getting a unicast IP
address assigned, and hence this authorization approach will not work
for multicast and something else may be needed anyway.
Of these I consider (c) to be the most serious.
Dave Oran (speaking as an individual, but with my IAB hat close at
hand).
_______________________________________________
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
