[rrg] Fundamental objections toahost-basedscalableroutingsolution

[Templin, Fred L]

Hi Chris,

>-----Original Message-----
>From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
>Sent: Saturday, November 29, 2008 11:48 AM
>To: Templin, Fred L
>Cc: tony.li at tony.li; 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
><Fred.L.Templin at boeing.com> 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
fred.l.templin at boeing.com
>
>-chris