On Wed, 25 May 2005, Alia Atlas wrote:
The TTL field in all IP packets used for transmission of messages
associated with GTSM-enabled protocol sessions MUST be set to 255.
This is a potentially new forwarding plane requirement. For all other
traffic, it is acceptable to decrement the TTL of packets egressing the
I don't understand what you're saying. This isn't a forwarding plane
requirement. It just says that the certain packets originated by the
router must have TTL set to specific value.
If the multi-hop GTSM were being used - why is it necessary to transmit with
Uhh, unless you send with TTL=255, the receiver can't verify what the
sender's TTL was (and the number of hops that were traversed)..
This makes the forwarding plane require more than just an existing ACL
lookup. Now, the look-up must contain not merely permit/deny, but
potentially a range of TTL values & the ability to check them. That can be
If the additional processing required for those particular packets subject to
the GTSM process were to cause the forwarding plane to be unable to due the
GTSM process at line-rate, then there's no benefit, I think.
I think it may be useful to describe that it is possible to support only the
single-hop GTSM - which gives the most security benefit, anyway. That seems
to me to be much simpler to implement with the currently existing ACLs.
Personally, I don't care for non-single-hop GTSM at all (and I think
it would probably be dangerous and requires an applicability
If it would be feasible, I'd move single-hop GTSM to standards track
while keeping multihop at experimental.
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
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.
This policy suggested for fragments seems to be merely the same policy that
could be applied to all packets, whether fragments or not.
Good idea; if the application protocol were to always set the DF bit,
then there should not be fragments to receive...
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Rtgwg mailing list