On Thu, Apr 25, 2013 at 11:15 AM, Satoru Matsushima <[email protected]> wrote: > On 2013/04/26, at 2:10, "cb.list6" <[email protected]> wrote: > >> On Thu, Apr 25, 2013 at 8:35 AM, Shishio Tsuchiya <[email protected]> wrote: >>> CB >>> MAP validate onsistency of the source IPv6 address and source port number >>> for the packet using BMR. >>> It dicribes section 8.1. >>> http://tools.ietf.org/html/draft-ietf-softwire-map-05#section-8.1 >>> >>> I can't understand why you are saying about open DNS resolver in this >>> question. >>> Basically MAP domain includes CE are managed by service provider. >>> MAP-CE should configure as it does not response for query from WAN. >>> >> >> i am mostly thinking of a rogue MAP-CE spoofing may cause lots of >> problems on the BR (port dos, already noted in the draft) and >> undermining the attribution features of MAP. > > While it looks as same as 6rd, DS-Lite and 464XLAT, what kind of things are > MAP specific. > >
That's a fair point. But, it is MAP that is in last call. My suggestion is about making MAP a better standard by adding a MUST implemented spoofing protection at the PE. Cameron >> If a criminal in a court >> can say spoofing is possible and anyone could have sent those illegal >> packets, then they can deny the attribution features of MAP. > > While it looks as same as 6rd, DS-Lte and 464XLAT, what kind of feature is > MAP specific. > >> It seems >> like if rogue MAP-CE spoofing is not explicitly denied at the >> attachment PE router with a "MUST use RFC 2827" in the >> draft-ietf-softwire-map, then there is a problem with the spec that >> should be resolved. So, the MAP team may want to add that. > > What you suggesting looks like making boiler-plate RFC that says "all kind of > IPv6 transition solutions MUST be deployed in network which is under RFC2827 > operation, that all." Or, applying that boiler-plate amendment to all > published RFCs. > > cheers, > --satoru > > >> >> >> >>> Regards, >>> -Shishio >>> >>> >>> (2013/04/26 0:07), cb.list6 wrote: >>>> Hi, >>>> >>>> Tom Taylor just sent a mail to behave on logging that piqued my interest. >>>> >>>> The MAP based solutions set is stateless. >>>> >>>> And therefore it has an elegant solution for those interested in >>>> attribution, specifically in the context of law enforcement. >>>> >>>> Can someone explain where I can find a pointer on how the stateless >>>> mapping holds up to spoofing from the MAP domain? Could a malicious user >>>> send bad packets where this attribution model attributes the bad packets >>>> to a 3rd party. >>>> >>>> If Alice and Bob are communicating, could Dec send a packets through the >>>> BR appearing to be from Alice where destination is Bob. >>>> >>>> Stateless is great. But there is no chance that the MAP BR is not the new >>>> open DNS resolver, right ? >>>> >>>> If this is already covered, a simple pointer is all I need. >>>> >>>> Will this type of attribution be sufficient for courts ? Or is it >>>> circumstantial ? >>>> >>>> CB. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
