The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-10

[Ballot comment]
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.

[Ballot comment]
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?)

[Ballot discuss]
Section 3., paragraph 4:
>          The TTL field in all IP packets used for transmission of
>          messages associated with GTSM-enabled protocol sessions MUST be
>          set to 255.  This also applies to related error handling
>          messages associated with said session, such as TCP RSTs or ICMP
>          errors.

  DISCUSS: I understand how ICMP messages are related to a session but
  not part of it, but TCP RST segments *are* part of a TCP session -
  they're normal TCP segments with the RST bit set. Please correct this
  here and elsewhere in the text.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
The discussion of fragmentation does not discuss attacks on integrity.
If you are accepting `unknown' packets into a protocol session , then
you may be accepting data provided by an attacker.  This seems like a
particularly serious concern with fragmented packets and needs to be
discussed in the security considerations section.

Proto writeup by John Scudder:

1.  Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID is
ready to forward to the IESG for publication?

    I have, and I do.  (Alex can answer for himself if he likes.)


2.  Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

    Considering that the document is a minor update to an existing
    RFC which has itself already been deployed, I think the level of
    review is adequate.


3.  Do you have concerns that the document needs more review from
a particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

    No.


4.  Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for it. In
any event, if your issues have been discussed in the WG and the WG
has indicated it that it still wishes to advance the document,
detail those concerns in the write-up.

    No.

5.  How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    Consensus can be broadly summarized as "silence indicates consent". 
    On the other hand, the document has been discussed in WG meetings
    more than once, is a minor update to an existing RFC, and has gone
    through a long WGLC.

6.  Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

    No.

7.  Have the chairs verified that the document adheres to all of
the ID Checklist items ?

    Yes.

8.  Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are
not also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

    Yes; no.

9.  What is the intended status of the document? (e.g., Proposed
Standard, Informational?)

    Proposed Standard.