Ted Lemon wrote, around 5/12/07 5:12 PM:
On Dec 5, 2007, at 4:52 PM, Peter Arberg wrote:
I think any NAS vendor will be supportive of implementing the
DSLF choosen authentication methoed for IP Sessions, if
it is DHCP Auth or PANA or something else :)
The reason I asked the question is that if it's pretty much all the
same to the vendors, and it would solve the problem, then it would be
expedient to go with the PANA solution. The reason it would be
expedient is that support for the DHCP option in the Internet Area
meeting was weak, and I suspect that of all the people who raised
their hands supporting it (e.g., me), a significant percentage would
have raised their hands in support of PANA as well. So you could get
a strong consensus really easily.
When I asked about this yesterday, Richard said that the reason for
choosing DHCP over PANA is that fewer elements in the network have to
change, but my superficial understanding of PANA suggests to me that
this is not actually the case. It seems to me that PANA can traverse
essentially the same path that DHCP relay packets traverse, given that
you're going to have to make a change on the BRAS anyway.
As I say, I'm not an expert in PANA, so I may have missed something,
but this is my naive understanding of the situation. And again, as I
say, I'm not a strong proponent of PANA - I'm just suggesting that we
do what is expedient, and will work, rather than fighting a pitched
battle for an alternative that in the final analysis probably isn't a
better choice, and fundamentally does pretty much the same thing.
The DHCP Authentication solution assumes that port marking (in DHCP
Option 82) and then the layer 2 network is secure by current features in
the DSLAM that are provisioned by DHCP snooping. Thus the DHCP
Authentication, while only being implemented on the Layer 3 edge and the
CPE, does secure the large layer 2 network in front of the layer 3
edge. Basically you cannot send a packet into the layer 2 network until
the DHCP ack is received (DHCP packets are obviously the only exception
to this).
Often my frustration in this dialog has been that people do not seem to
understand how big an issue this layer 2 secured edge is. A couple of
points to that:
- Firstly these metro and dsl aggregation networks can be large, 200K
subscribers sites connected common.
- Services like large content sources are deployed in the layer 2 networks.
- Multiservice and layer 2 content distribution are the main real
technical drivers to move from PPPoE.
PANA would require something to get identity from the layer 2 switch
directly connected to the subscriber site and then something else to
enforce policy in the layer 2 provider edge. This is a very different
implementation task but also means that the service edge which touches
millions of homes would need to implement and upgrade to whatever
spaghetti sauce control plain PANA propose to control the layer 2
switches at this edge. These are not big BRAS's with lots of memory and
CPU, these are small edge devices, built to be as cheap as possible,
providers are very, very reluctant to replace them with things that
could run a big control plain.
Personally I think the most likely result of specifying something that
needs an equipment upgrade to the layer 2 edge for SP's to deploy a
service without a cost advantage will probably be that we will see
deployment of proprietary authentication that do not inflict this cost
and operation hardship on the SP's.
- Ric
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
