[tcpm] Comments on the text in draft-ietf-tcpm-icmp-attacks-04.txt

[Gorry Fairhurst <[e-mail]>]

I volunteered to review this I-D in the TCPM meeting in MPLS, this email 
contains detailed comments on the text (but not the pseudocode). I may 
have more comments, depending on whether the answers to my other email 
also change my understanding of the draft.

Best wishes,

Gorry


---


Detailed notes/comments

These notes detail some of the document issues. A separate email 
highlights some issues that I feel are more significant.

Abstract, line 4:
/describes a/
- Insert /this also/ before the above clause.

Abstract
The abstract seems to match the title, but the majority of text 
describes the use or non-use of ICMP for selecting path MTU. If this is 
a major feature of the I-D, it should be reflected in the abstract.

Section 1, para 1
/allowing variety of/
          ^
- please insert 'a'

Section 2.1.1 does not review the guidance on PLPMTUD provided in RFC 4821.

Section 2.1.1 talks about source-quench. Is it possible to say this is 
historic in some way?

Section 2.1.1 also needs a ref to RFC4821 besides that of RFC1191.

Section 2.1.2 also needs to mention RFC 4821 (see previous note)

Section 2.3 has an unclear introduction to IPsec, I think it is missing 
a few sentences that define the basic terminology used later in the draft.

Section 3, para 1
- Identifies the small minimum payload of IPv4 ICXMP messages. In the 
light of extensive use of tunnels, it would be good to comment on the 
issues in receiving ICMP messages from routers on a tunnel path.

Section 3, para 3
- I do not understand how a portion of a signed segment actually helps 
more than any other valid packet header sent from the sending host.

Section 3, final para
/with every existing intermediate system/
- this seems extreme. Is it
/the set of routers along the path to the destination/

Section 4.1
/so makes TCP react only/
- this would be better written as:
/that makes a sender TCP only react/

Section 4.2
/increasing the port number range for outgoing/
-  This needs more detail: what does this mean?
- is this a practice endorsed by the IETF, a new procedure, or one that 
goes against an IETF recommendation?

/connection/ - spelling needs to be corrected.

Section 4.3
/can help to prevent users of the network being protected/
- This seems odd. Is this sentence correct?

Section 5.1, bullet 2
/and repeatedly retransmit its data/
- This needs clarification, is this a special procedure, or a standard 
TCP retransmit?

Section 5.1
/It is important to note that even if/
- please delete //It is important to note that/

Section 5.2
/It is interesting to note that as/
- please delete.

Section 5.2
/ USER TIMEOUT/  - should this be upper case?

Paragraph starting /In scenarios such that.../ reads curiously, please 
clarify the English.

Section 6.1/6.2
- The level of detail in the section ICMP Source Quench seems rather 
odd, given that networks have been discouraged to deploy this for many 
years and RFC1812 already in 1995 has stated "A router SHOULD NOT 
originate ICMP Source Quench messages." Do we need to pick-apart the 
vulnerability of a mechanism that is not recommended for use in the 
general internet? - I'd prefer a more concise description.

Section 7.1
/When one IP system has a large amount of data to send to another
    system, the data will be transmitted as a series of IP datagrams. /
- I think it's not necessarily so large!
- I think it would be bette to say the Internet architecture allows the 
sender to break data into a series of IP datagrams for transmission 
across the Internet - or something like that.

Section 7.1
/The basic idea behind the PMTUD mechanism is that a source system 
assumes that the
    MTU of the path is that of the first hop,/
- It's probably better language to say it sets upper bound to the 
interface MTU (is there really an assumption here, this seems like a 
search algorithm).

Section 7.1
/"fragmentation neeed and DF/
                    ^ - insert 'd'

Section 7.1
- This section discusses an increase in IRQ with packet rate. I do not 
believe this is necessarily so. Many Ethernet drivers are able to cope 
with rising packet rates without a corresponding increase in IRQ rate, 
but of course there will still be packet processing overhead as the I-D 
states.

The last two paragraphs appear to focus on IPv4-related issues, This 
would be clearer if the two paragraphs were reversed in their order.

Section 7.2
/The
    described mechanism basically disregards ICMP messages when a
    connection makes progress./
- This seems like the place to introduce PLPMTUD, and to relate 
subsequent sections to this framework.

Section 7.3
/SECTION/ should be /section/

Section 7.3
- This section talks about a proposed counter measure. Is this the same 
one that the I-D is seeking to document, or a different one?

Section 7.3
/simplicity sake/
             ^^^^
- please omit 'sake'

Appendix A, Type 3
- What is a valid action if the host has only sent packets with a DF=0, 
and receives this message - ignore?

Appendix A, final para
- The last paragraph seems a little odd in a working group draft. Does 
this actually reflect the consensus of the working group - can that 
consensus be clarified? - I do not know, see other email (or Chairs may 
comment).

Appendix B
Is the IETF happy with the advice in appendix B? - I have no comment on 
this.

The I-D talks about /intermediate systems/ but I think in this case we 
simply mean internet "routers" - was there a reason for this choice of 
words, or can we use router throughout?



_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm