RE: Liaison from BBF

["Wojciech Dec (wdec)" <[e-mail]>]

I'd like to put forward some additional points which should perhaps be
concise enough to clarify the liaison and questions a bit more. 
There are actually two issues, out of which the duplicate MAC address
issue is IMO a far less tractable problem (as it needs to be solved at
L2 for anything to work).
1. Within a shared L2 domain with constrained forwarding (aka NBMA), for
two users A & B with *different* MAC addresses, user B may spoof the LL
address of user A and thus lead possibly to a DoS attack (on a FCFS
basis). Similarly user B may try to spoof the LL address of N users
(again on an FCFS basis). Does SAVI propose to solve this problem and if
so how?

2. A duplicate MAC address in a shared broadcast domain is a
possibility. 
At L2, this problem is tractable by any one of
a) denying the dupe addresses access to the network service on a FCFS
basis (common practice today)
b) assigning each duped MAC to a different broadcast domain
c) MAC address translation (MAC NAT). 
Solution c) requires some form of ALGs (for v4 and v6). Eg In the v6
case any EUI-64 derived LL addresses will still be the same and thus an
ND ALG appears needed. What is the IETF's opinion about this type of
solution (c), if any?

Regards,
Woj.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of David Allan I
> Sent: 10 November 2009 00:31
> To: Thomas Narten
> Cc: [e-mail]
> Subject: RE: Liaison from BBF
> 
> HI Thomas:
> 
> Unfortunately having just changed jobs I'm having trouble 
> exactly recreating all my sources of information...
> 
> The following was one anecdotal example offered during our 
> discussions in the spring..."...in a real nationwide telco 
> today with approximately 3.5million DSL ports there is about 
> 300-400 duplicate MAC@ alarms active on the DSLAMs at any 
> time, and this is only where 2 of the same MAC@ appear on the 
> same DSLAM (384-1000 users each)..."
> 
> TO take it back up a notch...
> 
> In a perfect world where all MACs were properly unique and 
> all implementations correctly constructed link local via 
> EUI-64 we'd all be happy campers, it works as intended. 
> Unfortunately that is not the case and we seem to have a 
> hierarchy of grief.....
> 
> 1) Some carriers have deployed MAC address translation in the 
> Access node/DSLAM to ensure MAC uniqueness. This means ALG 
> functionality is required for Ethernet OAM and other 
> protocols, and while fixing MAC uniqueness, does not address 
> duplicates in link local construction unless NAT of the lower 
> 64 bits of LLA is included in the mix.
> 
> 2) Our liaisons with IEEE on the subject and some proposals 
> to the forum focus on the fact that uniquness only needs to 
> exist in a given Ethernet broadcast domain, hence keeping a 
> few extra VLANs in the back pocket to shift duplicate 
> customers to solves the problem, and my math suggested this 
> would inflate VID usage by a corresponding few percent. Issue 
> being this then breaks down if the link local address is not 
> constructed from the MAC, and RFCs have been trotted out at 
> the BBF on NOT using the EUI-64 specifically to defeat 
> traffic analysis attacks. This being an expected deployment 
> scenario when wireless media in the home is considered and an 
> emerging class of FMC capable terminals is deployed. 
> 
> So a solution analogous to DAD appears to be needed, that 
> originates with the edge router, where if the detected 
> duplicate does not subsequently behave in a prescribed manner 
> service may then be denied in the interest of the common 
> good. As DAD is already deployed that would appear to be a 
> path of least resistance vs waiting years for a roll out of a 
> fix. However if my memory serves correctly, unicast from the 
> edge router would be a desirable form and I am unsure if that 
> is supported in standards or implementations...
> 
> Cheers
> D
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Thomas Narten [mailto:[e-mail]]
> Sent: Tuesday, November 10, 2009 12:00 AM
> To: David Allan I
> Cc: [e-mail]
> Subject: Re: Liaison from BBF
> 
> Sorry, I still don't get it. We need more detail!
> 
> Two things stand out:
> 
> > If two devices happen to have the same Ethernet MAC address as a 
> > consequence of incompetent manufacture, the link-local 
> address derived 
> > for that interface will also be non-unique, provided it is derived 
> > from the EUI-64 identifier. This has been identified as an 
> > inconveniently frequent scenario (impacting ~4% of access 
> nodes at any 
> > given time)
> 
> this 4% figure seems *very* high. Can you please provide more 
> details on how you reached that number?
> 
> Also, if you have two devices on the same link sharing the 
> same MAC address, you have problems. Period. Having duplicate 
> IP addresses is only one symptom. If you fix that problem, 
> but still have duplicate MAC addresses in use, it is not 
> clear to me that your network will function correctly. Have 
> you done the analysis to be sure that the duplicate MAC 
> address scenario is something that is solvable in practice?
> 
> > When numerous hosts share an Ethernet broadcast domain, the 
> BNG/edge 
> > router needs to support a mechanism that ensures duplicate 
> link-local 
> > addresses can be handled correctly without necessarily depending on 
> > cooperative action by the hosts
> > 
> > it is explicitly required to do something to make this happen
> 
> Again, it is not clear to me what "handling correctly" even means.
> 
> Finally, the charts say you are worried about a "malicious user"
> sending out bogus ND packets. ND simply can't deal with this 
> sort of hostile environment, and there is no easy way to fix 
> this. Is that what you are asking this group to fix?
> 
> For that matter, ARP doesn't address this problem either. Is 
> there a new problem that shows up with IPv6 that didn't exist 
> with IPv4? And if not, what is wrong with using the IPv4 
> solutions (assuming they exist)?
> 
> Thomas
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>