On Fri, Apr 26, 2013 at 7:50 AM, Rajiv Asati (rajiva) <[email protected]> wrote: > > Typically, an IP address pertains to a CPE. So, a common BCP is to employ > uRPF to detect/mitigate the source-address spoofing. > > In A+P environment (such as that of MAP), an IPv4 address + port-range > pertain to a CPE. So, it is tempting to think that the port-range aware > uRPF is needed to avoid the source-address-port spoofing. > > Thankfully, in MAP, both CE and BR employ the so called port-range aware > uRPF, as Ole well clarified. So, the possibility of any device causing any > grief to any other device (in the network - CE or outside the network - > via BR) just does NOT exist. > > Of course, the source IPv6 address used by the MAP CE is still very much > subjected to the typical uRPF on any IP node in the network. > > All-in-all, MAP nodes (e.g. CE) can't become " open DNS resolver" or > attribute the bad packets to a 3rd party. > > I don't expect any changes in the MAP spec. >
Ok, let me explain a possible threat and you tell me if existing countermeasures are sufficient. A rogue map ce starts sending malicious random SYN flood traffic to the BR. The rogue CPE is spoofing addresses from the MAP domain. It cycles through source addresses and port pairs. My thought is urpf on the attachment pe would limit this issue CB. > Cheers, > Rajiv > > -----Original Message----- > From: Ole Troan <[email protected]> > Date: Friday, April 26, 2013 5:20 AM > To: Simon Perreault <[email protected]> > Cc: Softwires-wg list <[email protected]> > Subject: Re: [Softwires] MAP based attribution and spoofing > >>Simon, >> >>>>> My concern is at the rogue MAP CE. Thus, the spoof protection >>>>> filtering should be applied at the attachment PE so that the rogue MAP >>>>> CE attempts at spoofing can squashed at the provider edge. >>>>> >>>>> Make sense? >>>> >>>> yes, that was what I meant too (albeit not what I wrote ;-)). >>>> the receiving consistency check has to be done both on BR and CE. >>> >>> That is still not answering Cameron's point IMHO. >>> >>> - First, doing spoof prevention on the BR doesn't prevent spoofed >>>packets from reaching other MAP CEs directly. Second, it allows packets >>>to travel across the ISPs network: ideally you'd want to drop them at >>>the edge (PE). >> >>every MAP node does the spoof protection. that prevents spoofed packets >>from reaching other the MAP CEs. >>as a deployment consideration, the borders of the MAP domain should be >>protected to hinder tunnelled packets >>escaping or entering. >> >>> - Doing spoof prevention on the CE prevents nothing because it's a >>>rogue CE you're trying to protect the network against. >> >>doing it on the CE (as well as on the BR) prevents other CEs in the same >>domain accepting traffic from the rogue CE. >> >>> As I understand it, Cameron is suggesting that the PE inspect inside >>>IPv6 packets encapsulating IPv4 packets to apply the MAP spoof check on >>>the IPv4 source address. This would prevent spoofed MAP packets (correct >>>external IPv6 source but spoofed internal IPv4 source) from reaching >>>the BR or other MAP CEs. >>> >>> Makes sense to me. >> >>you are saying that every PE needs to know the MAP rules. isn't that >>making them into a MAP BR? >>in any case, the MAP specification should not specify behaviour on >>non-MAP nodes. >> >>cheers, >>Ole >> >>_______________________________________________ >>Softwires mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
