The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-10
Yes
(David Ward)
(Ross Callon)
No Objection
(Chris Newman)
(Cullen Jennings)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 10 and is now closed.
David Ward Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
(2007-06-21)
Unknown
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 Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2007-06-18)
Unknown
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.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2007-06-20)
Unknown
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?)
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(2007-06-18)
Unknown
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.
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
(2007-06-17)
Unknown
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.
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown