>> >> >>This policy suggested for fragments seems to be merely the same policy
>> >> >>that could be applied to all packets, whether fragments or not.
>> Not for all, but for all Unknown, and yes, my original comments did say
>> that for Unknown too.
> Given that implementing GTSM for a particular protocol is to try and
> protect it against such DOS attacks, letting the fragments have to
> compete for resources with Unknown seems to make this much less useful
> - as far as the multi-hop case goes.
What's the alternative?
>> >> >Good idea; if the application protocol were to always set the DF bit,
>> >> >then
>> >> >there should not be fragments to receive...
> Are there protocols where it is the case that both fragments are
> commonly seen and the multi-hop case is necessary?
OSPF VLs. On the other hand, they are not very widely deployed.
I don't recall anything else that doesn't run over TCP.
>> Right. It's straight-forward with single-hop. With multi-hop, we should be
>> able to tell Unknowns from Dangerous.
> Since it is straight-forward with single-hop, why don't we call this
> out in the draft as a special case where fragments with TTL=255 are
> trusted? At least that makes the single-hop case more useful.
Seems a good idea to me. I would probably still check the IP addresses
though to make sure we don't mix frags from trusted neighbors with those
Rtgwg mailing list