Note: This ballot was opened for revision 09 and is now closed.
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
Jari Arkko
Comment (2007-06-21)
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.
[Dan Romascanu]
Comment (2007-06-18)
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.
[Lars Eggert]
Comment (2007-06-20)
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?)
[Ron Bonica]
Comment (2007-06-18)
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.
[Sam Hartman]
Comment (2007-06-17)
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.
datatracker.ietf.org
