[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Layer 2 access and Current Practices



The WG Charter says:

The working group will list capabilities appropriate for
devices use in:

* Internet Service Provider (ISP) Networks
* Enterprise Networks

The following areas are excluded from the charter at this time:

* Wireless devices
* Small-Office-Home-Office (SOHO) devices
* Security devices (firewalls, Intrusion Detection Systems,
Authentication Servers)
* Hosts

I think that means most of the broadband aggrigator and CPE questions below 
are out of scope.

I think the fact that port security is not  used (per Merike's survey)
 in larger ISPs
speaks to either A) it's difficulty to use or B) it's lack of preceieved benfit.

I could be argued into paying more attention to it in the drafts
(well, those that I'm
involved in such as filtering) if it can be shown that A) it would be
used if made
more simple/effective B) operators can be shown to see a precieved benefit.

Thanks,
---George Jones


On Wed, 16 Feb 2005 18:56:37 -0500, Howard C. Berkowitz
<hcb@gettcomm.com> wrote:
> In the Current Practices document, is it worth distinguishing between
> those providers that operate a L1/L2, especially Ethernet-over-XXX,
> customer access subsystem, as opposed to those that accept aggregates
> from separate broadband service providers?  Should the document
> define a broadband aggregator as a type of provider? Consider this
> distinction with respect to:
> 
> 2.4.4  Additional Considerations
> 
>     For layer 2 devices, MAC address filtering and authentication is not
>     used.  This is due to the problems it can cause when troubleshooting
>     networking issues.  Port security becomes unmanageable at a large
>     scale where 1000s of switches are deployed.
> 
> In the case where the operator does support end user broadband
> connectivity, it is not arguable that certain forms of port security
> are unmanageable. At one time, when DSL and cable devices were
> installed by other than the customer, it was reasonable to let the
> customer ingress switch port learn the MAC address at installation,
> and filter on it. That is unrealistic with customer-installed direct
> computer connection, where the MAC address would change with any NIC
> replacement. It might be worth considering as a special case, where
> the CPE is provider controlled.



> 
> We do want to be clear about the scope of port security. Is the
> definition here strictly L2, or could it include a port-oriented
> 802.1x proxy to RADIUS?
> 
>     Rate limiting is used by some ISPs although other ISPs believe it is
>     not really useful since attackers are not well behaved and it doesn't
>     provide any operational benefit over the complexity.  Rate limiting
>     can be improved by (need info)'
> 
> I'm not sure if this is the improvement you had in mind, Merike, but
> rate limiting at layer 2 will be much more important if the L2
> connectivity includes end user, easily compromised hosts.  L2 rate
> limiting within the provider infrastructure seems a much lower
> priority.
> 
> Even if the operator supports direct customer L2 connectivity at
> broadband rates, there is still a tradeoff between rate limiting at
> the port level and, assuming there is L2 aggregation before the
> ingress router, doing rate limiting at the access switch uplink.
> 
> Do the providers that rate limit do it on simple frame count, or do
> they have additional restrictions for multicasts and broadcasts?
> 
>