>> >>> o Such unidentified fragments SHOULD NOT be classified as Trusted
>> >>> o Such unidentified fragments SHOULD NOT be dropped (as part of GTSM
>> >>> operation) by default.
>> >>Could this issue be handled by requiring DF be set? And the MTU used by
>> >>a protocol configured?
I'm not sure about this. IP fragments carrying a large OSPF packet are seen
in practice more than one would expect and DF'ing them would break OSPF's
This means the condition (TTL==255) && (!fragment) isn't a clear cut
anymore and you have to look further again.
>> >>If unidentified fragments are classified as Unknown and Unknown packets
>> >>can share resources with Trusted, then there doesn't seem to be much
>> >>additional security from the mechanism. The attacker can just send
>> >>fragments instead.
The approach I took in my comments on this doc was to leave the exact
details of how resources are separated for different classes to the
implementor and admin, and only specify what needs to be specified--the
defaults and only to make sure enabling GTSM doesn't bring the network
So, what you say is correct. I'm just not sure we can or should capture
every valid choice here. I.e., one may want the GTSM defaults wrt Unknown
and Trusted separation is concerned to be exactly what they are without
GTMS--i.e. the same queue. That would be a valid design choice.
>> >>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.
>> >Good idea; if the application protocol were to always set the DF bit, then
>> >there should not be fragments to receive...
>> Alternately, if one were only doing single-hop GTSM, then trusting
>> fragments with a TTL of 255 wouldn't be a concern.
Right. It's straight-forward with single-hop. With multi-hop, we should be
able to tell Unknowns from Dangerous.
Rtgwg mailing list