Hi Chris, >-----Original Message----- >From: Christopher Morrow [mailto:[EMAIL PROTECTED] >Sent: Saturday, November 29, 2008 11:48 AM >To: Templin, Fred L >Cc: [EMAIL PROTECTED]; Darrel Lewis (darlewis); Routing Research Group Mailing List >Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution > >On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L ><[EMAIL PROTECTED]> wrote: >>>|> That implies that the >>>|> ETR does a mapping lookup on the receipt of a packet, buffers >>>|> the packet until the lookup succeeds, and the does the >>>|> compare. >>>| >>>|Oh you mean like the IPv6 neighbor discovery process!? >>> >>> >>>Two wrongs don't make a right. >> >> Why buffer the packet until the lookup succeeds? Why not >> just accept the first few packets while a lookup is done > >a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! :( >Seriously though, if you send through 'some' of the bad packets all >the attacker has to know is how many 'some' is... in the worst case >the answer is 'one'.
Still, AFAICT performing egress filtering of some sort during decaps could be used to the ETR's advantage in establishing a pattern of behavior from certain ITRs. In particular, it could be used by the ETR to determine which ITRs are not correctly implementing ingress filtering - right? >Buffering is bad, really, really bad. Buffering on decaps does sound pretty bad, but buffering on encaps may be a different story. I haven't looked at the mapping schemes all that closely, but at least the APT approach seems to have the ITR send to a "default mapper" with side-effect of getting a mapping resolution in return. That sounds great, but it essentially puts "default routers" in the DFZ. Is that better or worse than buffering? Fred [EMAIL PROTECTED] > >-chris _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
