The Generalized TTL Security Mechanism (GTSM)
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 09 and is now closed.
Jari Arkko Yes
Comment (2007-06-21 for -)
Section 5.4 conclusions apply only if the GTSM processing cannot associate initial and non-initial fragments to each other. There does not seem to be any reason why this could not be done; the GTSM processor is the receiver of the packets and can look at the identifier field. If the initial fragment belongs to a session, the non-initial fragments have the same identifier, and all fragments satisfy the TTL criteria, it would seem that we can make equally strong conclusions about the packet as we can from a non-fragmented packet. Am I missing something? Anyway, I fully support the recommendation to use path MTU discovery and avoiding fragments. Please consider the above question mostly from an acamedic interest point of view.
( Ross Callon ) Yes
( David Ward ) Yes
( Ron Bonica ) No Objection
Comment (2007-06-18 for -)
Section 6: The applicability statement is pretty good about saying that the value of GTSM is inversely proportional to the hop-count between the neighboring peers. However, you might want to add a sentence that says that GTSM will not protect you against attackers who are as close to the protected station as its legitmate peer. For example, if the legitimate peer is one hop away, GTSM will not protect from attacks from directly connected devices.
( Lisa Dusseault ) No Objection
( Lars Eggert ) (was Discuss) No Objection
Comment (2007-06-20 for -10)
Section 5.4., paragraph 3: > As such, it is highly recommended for GTSM-protected protocols to > avoid fragmentation and reassembly by manual MTU tuning, using > adaptive measures such as Path MTU Discovery (PMTUD), or any other > available method. Suggest to add a reference to RFC 4821 for PMTUD and make it the preferred alternative for avoiding fragmentation. (And shouldn't this be a capital RECOMMENDED?)
( Sam Hartman ) (was Discuss) No Objection
Comment (2007-06-17 for -10)
I dislike it when documents speak of "trusted" packets, interfaces or peers without a discussion of what they are trusted to do. In this instance, I think all devices on a trusted interface are trusted not to originate packets with spoofed source address, hop limit or TTL. Also, the physical hardware of trusted links is trusted not to have unintended peers on the link. It would be great if this were refined and included in the document.
( Russ Housley ) No Objection
( Cullen Jennings ) No Objection
( Chris Newman ) No Objection
( Jon Peterson ) No Objection
( Tim Polk ) No Objection
( Dan Romascanu ) No Objection
Comment (2007-06-18 for -)
There is no place in the document that mentions that this standards track RFC would obsolete an Experimental RFC. I believe that the Abstract and the Appendix B 'Changes Since RFC3682' should mention that 3682 was Experimental.