Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-09.txt

From: [email-masked]
Date: Tue, 19 Jan 2010 17:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : ICMP attacks against TCP
	Author(s)       : F. Gont
	Filename        : draft-ietf-tcpm-icmp-attacks-09.txt
	Pages           : 40
	Date            : 2010-01-19

This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols.
Additionally, describes a number of widely implemented modifications
to TCP's handling of ICMP error messages that help to mitigate these
issues.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 23, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Jan 2010 15:35:21 +0200

Hi,

below is my AD review for draft-ietf-tcpm-icmp-attacks-09.

I have one main issue. The very detailed example of the operation of the mitigation technique in Section 7.3, and especially the pseudo code that implements what the document still calls the "proposed" solutions in Section 7.4 in my opinion go beyond the WG consensus we had, which was to document and discuss the mitigation techniques implemented in current stacks.

I'd be interested to hear the WG's thoughts esp. on this issue, but of course also on the rest of my comments below.

Thanks,
Lars

  Note: Most comments marked as nits below have been automatically
  flagged by review scripts - there may be some false positives in
  there.

  The goal of this draft is to document and discuss attack mitigation
  techniques that are implemented by various stacks. In some places, the
  ID still talks about "proposed mechanisms" or "proposed techniques",
  etc., which isn't quite aligned with the purpose of the draft. Could
  you check those phrasings and change them to be about what the
  surveyed implementations do?

>    Transmission Control Protocol (TCP) and other similar protocols.

  I find nothing in this document that is not about TCP. Suggest to
  remove the "and other similar protocols" bit.

> Copyright Notice

  You're using the IETF Trust Provisions' Section 6.b License Notice
  from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
  http://trustee.ietf.org/license-info/)

Section 1., paragraph 2:
>    official proposal on how to deal with these vulnerabiliies.  In 2005,

  Nit: s/vulnerabiliies./vulnerabilities./

Section 1., paragraph 5:
>    This document aims to raise awareness of the use of ICMP to perform a
>    variety of attacks against TCP, and discusses several counter-
>    measures that eliminate or minimize the impact of these attacks.
>    Most of the these counter-measures can be implemented while still
>    remaining compliant with the current specifications, as they simply
>    describe reasons for not taking the advice provided in the
>    specifications in terms of "SHOULDs", but still comply with the
>    requirements stated as "MUSTs".

  Recommend to add a sentence that this document does NOT constitute an
  IETF recommendation to implement said countermeasures, and why.

Section 1., paragraph 6:
>    Section 2 provides background information on ICMP.  Section 3
>    discusses the constraints in the general counter-measures that can be
>    implemented against the attacks described in this document.
>    Section 4 proposes several general validation checks that can be
>    implemented to mitigate any ICMP-based attack.  Finally, Section 5,
>    Section 6, and Section 7, discuss a variety of ICMP attacks that can
>    be performed against TCP, and propose attack-specific counter-
>    measures that eliminate or greatly mitigate their impact.

  See the first comment - the purpose of this document is not to propose
  or recommend any techniques. Please rephrase. (I'll not flag this in
  the remainder of the ID; please check it for such phrasings though.)

Section 2.1., paragraph 2:
>    When an intermediate router detects a network problem while trying to
>    forward an IP packet, it will usually send an ICMP error message to
>    the source system, to raise awareness of the network problem taking
>    place.

  Nit: suggest to say "inform" rather than "raise awareness" - ICMP is
  not part of some sort of PR campaign :-) (also elsewhere in the
  document)

Section 2.1., paragraph 3:
>      In the same way, there are a number of scenarios in which an
>    end-system may generate an ICMP error message if it finds a problem
>    while processing a datagram.  The received ICMP errors are handed to
>    the corresponding transport-protocol instance, which will usually
>    perform a fault recovery function.

  The first sentence is about generating ICMP, the second about
  receiving it. Move the second sentence to the previous paragraph,
  which was all about receiving ICMP?

Section 2.1., paragraph 4:
>    It is important to note that ICMP error messages are unreliable, and

  Nit: s/unreliable/transmitted unreliably/

Section 2.1.1., paragraph 0:
> 2.1.1.  ICMP for IP version 4 (ICMP)

  For completeness sake, you might want to add a sentence about & a
  reference to RFC4884.

Section 3., paragraph 0:
> 3.  Constraints in the possible solutions

  This section dances around the main issue without ever explicitly
  stating it: If a host wants to more carefully inspect ICMP messages
  before acting on them, it is limited by whatever chunk of the packet
  that triggered the ICMP the sender chose to include. And the situation
  is difficult, because <rest of section>.

Section 3., paragraph 2:
>    can be performed, as there is not much information avalable on which

  Nit: s/avalable/available/

Section 3., paragraph 6:
>    power requirements of authentication might not allow IPSec

  Nit: s/IPSec/IPsec/ (also elsewhere in the ID)

Section 4.2., paragraph 2:
>    [I-D.ietf-tsvwg-port-randomization] discusses a number of algorithms
>    to randomize the ephemeral ports used by clients.

  And in it, the IETF does recommend that clients use some form of port
  randomizartion, right?

Section 3.2.2.1, paragraph 4:
>    [I-D.ietf-tcpm-tcpsecure], by means authentication at the network

  Nit: s/by means/by means of/

Section 5.2., paragraph 13:
>    Based on this analysis, most popular TCP implementations treat all

  Odd wording. I doubt that the analysis in this ID has caused existing
  TCP implementations to change years ago. Do you mean "An analysis of
  most popular TCP implementations has shown..."?

Section 5.2., paragraph 15:
>    contition, and thus may still abort their connections on their own if

  Nit: s/contition,/condition,/

Section 5.2., paragraph 19:
>    This counter-measure has been implemented in BSD-derived TCP/IP
>    implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more
>    than ten years [Wright][McKusick].  The Linux kernel has also
>    implemented this policy for more than ten years [Linux].

  Which counter-measure is "this counter-measure"? The one that is
  implemented in most stacks, which is described four paragraphs before?

Section 7.1., paragraph 1:
>    systems determine the Path MTU of an arbitrary internet path.

  Nit: s/internet/Internet/ (also in many other places in the ID)

Section 7.1., paragraph 6:
>    The effect of this attack is two-fold.  On one hand, it will increase
>    the headers/data ratio, thus increasing the overhead needed to send
>    data to the remote TCP end-point.  On the other hand, if the attacked
>    system wanted to keep the same throughput it was achieving before
>    being attacked, it would have to increase the packet rate.  On
>    virtually all systems this will lead to an increase in the IRQ
>    (Interrrupt ReQuest) rate and protocol processing time, thus

  Nit: s/(Interrrupt/(Interrupt/

>    increasing processor utilization, and degrading the overall system
>    performance.

  I thought most modern operating systems didn't use hard IRQs anymore
  in their stacks? Isn't it all soft-interrupts or similar now? (I do
  agree that packet processing overhead per payload byte goes up with
  smaller packets, but I don't think it's because of IRQs.)

Section 7.1., paragraph 8:
>    results.  Another posible scenario is that in which a TCP connection

  Nit: s/posible/possible/

Section 7.2., paragraph 1:
>    The IETF has standardized a Path-MTU Discovery mechanism called
>    "Packetization Layer Path MTU Discovery" that does not depend on ICMP
>    error messages.  Implementation of the aforementioned mechanism in
>    replacement of the traditional PMTUD (specified in [RFC1191] and
>    [RFC1981]) would eliminate this vulnerability.  However, it might
>    also lead to an increase of the PMTUD convergence time.

  Add a citation to RFC4821 here. Also, why the conjunctive? PLPMTUD
  *does* eliminate this vulnerability.

Section 7.2., paragraph 11:
>    On the other hand, maxsizeacked holds the size (in octets) of the
>    largest packet that has so far been acknowledged for this connection.
>    It is initialized to 68 (the minimum IPv4 MTU) when the underlying
>    internet protocol is IPv4, and is initialized to 1280 (the minimum
>    IPv6 MTU) when the underlying internet protocol is IPv6.  Whenever an
>    acknowledgement for a packet larger than maxsizeacked octets is
>    received, maxsizeacked is set to the size of that acknowledged
>    packet.

  Maybe I'm dense, but how does this work with delayed ACKs? If you see
  the left edge of the window shift by n bytes, you don't know that
  maxsizeacked is n bytes, right?

Section 7.2., paragraph 15:
>    out.  MAXSEGRRTO specifies the number of times a given segment must

  Nit: s/MAXSEGRRTO/MAXSEGRTO/

Section 7.2., paragraph 20:
>    MAXSEGRTO can be set, in principle, to any value greater than or
>    equal to 0.  Setting MAXSEGRTO to 0 would make TCP perform the
>    traditional PMTUD mechanism defined in [RFC1191] and [RFC1981].  A
>    MAXSEGRTO of 1 provides enough protection for most cases.  In any
>    case, implementations are free to choose higher values for this
>    constant.  MAXSEGRTO could be a function of the Next-Hop MTU claimed
>    in the received ICMP "Packet Too Big" message.  That is, higher
>    values for MAXSEGRTO could be imposed when the received ICMP "Packet
>    Too Big" message claims a Next-Hop MTU that is smaller than some
>    specified value.

  Which value do the different implementations you surveyed use for
  MAXSEGRTO?

Section 7.2., paragraph 22:
>    Section 7.3 shows the proposed counter-measure in action.
>    Section 7.4 shows the proposed counter-measure in pseudo-code.

  Since the publication target is Informational, calling this the
  "proposed" something is slightly misleading. Can you rephrase this to
  be about what current implementations do?

Section 7.3., paragraph 0:
> 7.3.  The counter-measure for the PMTUD attack in action

  DISCUSS: Section 7.3 is in my opinion going into way too much detail
  for the purposes of this ID. The extremely detailed example in
  Sections 7.3.1-7.3.4 should really go into a specification of the
  mitigation technique (for which we have no WG consensus) and is IMO
  not needed in this Informational document.

Section 7.3., paragraph 1:
>    This SECTION shows the proposed counter-measure for the ICMP attack

  s/SECTION/section/

Section 7.4., paragraph 0:
> 7.4.  Pseudo-code for the counter-measure for the blind performance-
>       degrading attack

  DISCUSS: I believe it is fully out of scope for this Informational
  document to include pseudo code for a mechanism that the WG has
  decided to not recommend as PS.

Section 7.4., paragraph 33:
>       All comparisions between sequence numbers must be performed using

  Nit: s/comparisions/comparisons/

Section 7.4., paragraph 34:
>       sequence number arithmethic.

  Nit: s/arithmethic./arithmetic./

Appendix A., paragraph 16:
>    o  The text (particulary that which describes the counter-measures)

  Nit: s/(particulary/(particularly/

Appendix A., paragraph 19:
>    o  Miscelaneous editorial changes.

  Nit: s/Miscelaneous/Miscellaneous/

Appendix A., paragraph 25:
>    o  Corrected the threat analysys

  Nit: s/analysys/analysis/

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2010 17:20:50 -0300

Hi, Lars,

Comments in-line.... (other comments in my next e-mail...)

> I have one main issue. The very detailed example of the operation of 
> the mitigation technique in Section 7.3, and especially the pseudo 
> code that implements what the document still calls the "proposed" 
> solutions in Section 7.4 in my opinion go beyond the WG consensus we 
> had, which was to document and discuss the mitigation techniques 
> implemented in current stacks.

The pseudo-code is just that: documentation of how the counter-measure
works. While there's also verbose description of how the counter-measure
works, I'd argue that for many of us the pseudo-code ends-up being a
clearer explanation.

That said, this text has been in the I-D since
draft-gont-tcpm-icmp-attacks-04.txt (circa September 5, 2005), when it
had not yet been adopted as a wg item. I has been four and a half years
since that, an plenty of revisions since then. And the I-D has passed WGLC.

> I'd be interested to hear the WG's thoughts esp. on this issue, but 
> of course also on the rest of my comments below.

Are we kinda going back to WGLC?

> Section 1., paragraph 5:
>> This document aims to raise awareness of the use of ICMP to perform
>>  a variety of attacks against TCP, and discusses several counter- 

Being an informational document, it does not constitute an IETF
recommendation.

That said, why it's not a formal IETF recommendation... that's a very
good question, that not only me, but also vendors would like to know the
answer.

I do recall somebody making a comment in an IETF meeting that I attended
(back in 2005), asking "why not informational?", and we ended up
changing from std track to informational.

It remains an interesting question why we insist in ignoring
reality-based world.... (but you know I have already debated this one).

If you ask this question again, I'm afraid you'll get a response from
me, and another one from Joe (and probably not many others). Vendors,
and people in general working in real-world code have already applied
most of the stuff discussed in the I-D, and probably won't bother
getting into this type of debate.

Actually, all this endless debates about "you might receive an ICMP
error message after five minutes... so you shouldn't implement this", or
"it's incorrect to do this unless you know for sure you're under attack"
is IMO far from the "E" in "IETF", and the reason many of the
implementers we'd need to join the list, don't. We're seen as not
belonging to reality-based world.

> not needed in this Informational document.

Again, this has been in the I-D for more than four years (these
particular sections even predate the pseudo-code). And they document and
explain the counter-measure. If we don't include this, the reader has to
figure this out for himself. I don't know why we insist so much in
making documents irrelevant, rather than useful, to the reader.

>> 7.4.  Pseudo-code for the counter-measure for the blind 
>> performance- degrading attack
> 

The document was adopted with this section in place, has gone through
plenty of revisions since then (i.e., 2005), has been reviewed by
implementers more than probably any other I-D that this working group
has produced, and has passed WGLC with this text in place.

This is not the first time that you seem to ignore wg consensus (it has
happened with the draft-ietf-tcp-security already, as noted off-list at
the time). IMO, this discourages people in general, and particularly
implementers, to get involved in the IETF process in general, and with
TCPM in particular.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2010 17:37:00 -0300

Hi, Lars,

This is the rest of my response to your review.

Comments in-line.... (I have removed those changes that I will apply as
suggested, and that didn't require further discussion).

> techniques that are implemented by various stacks. In some places, 
> the ID still talks about "proposed mechanisms" or "proposed 
> techniques", etc., which isn't quite aligned with the purpose of the 
> draft. Could you check those phrasings and change them to be about 
> what the surveyed implementations do?

Yes, I will. Regarding the document calling it (or other stuff)
"proposed" solutions, that is something that I should fix (I thought I
had done it, already... but apparently there are remaining bits of it).

> remove the "and other similar protocols" bit.

Will do.

>  http://trustee.ietf.org/license-info/)

There was no way (other manual) to fix this (at least when the last rev
of the document was published). That said, the "grace period" announced
by the IETF Trust still lasts till February 1st, so there's no problem
with the old boilerplate text.

>>  while processing a datagram.  The received ICMP errors are handed 
>> to the corresponding transport-protocol instance, which will 
>> usually perform a fault recovery function.
> 

Sorry, I do not follow you. In the second paragraph of Section 2.1, the
first two sentences are about packet generation (first one about ICMP
generation by routers, and the second about ICMP generation by hosts).
Then the third sentence is about ICMP processing. So I'm not sure hwo
you'd like the text to be changed...

> For completeness sake, you might want to add a sentence about & a 

Will do.

>  that triggered the ICMP the sender chose to include. And the 
> situation is difficult, because <rest of section>.

Will do.

>> [I-D.ietf-tsvwg-port-randomization] discusses a number of 
>> algorithms to randomize the ephemeral ports used by clients.
> 

Yes. I will rephrase this.

>  most popular TCP implementations has shown..."?

No, I meant what I wrote: Those implementations that already included
the hard_errors -> soft_errors processing did so for the same reason
stated in the draft (e.g., I did talk with Kirk McKusick back in 2005
and these guys (and others) got to the same conclusion (e.g.,
hard-errors -> soft-errors) through the same analysis). That said, other
implementations implemented this in response to this I-D (e.g., Cisco,
Microsoft, and others). Please see the "ICMP attacks" advisories linked
in: http://www.gont.com.ar/advisories/index.html (and there are others).

> implemented in most stacks, which is described four paragraphs 

Yes. The whole Section 5.2 is about the same thing (hard_errors ->
soft_errors).

> Nit: s/internet/Internet/ (also in many other places in the ID)

I did mean "internet". The mechanism works if you're using it in e.g. a
corporate network that is not connected to the Internet.

>  smaller packets, but I don't think it's because of IRQs.)

Would you be happier with "increased interrupt and context-switching rate"?

>> "Packetization Layer Path MTU Discovery" that does not depend on 
>> ICMP error messages.  Implementation of the aforementioned 
>> mechanism in replacement of the traditional PMTUD (specified in 
>> [RFC1191] and [RFC1981]) would eliminate this vulnerability. 
>> However, it might also lead to an increase of the PMTUD convergence
>>  time.
> 

PLPMTUD can be implemented with or without ICMP support (i.e., as a
replacement for classical PMTUD, or for black-hole detection).
Therefore, it does not necessarily eliminate this vulnerability.

>> largest packet that has so far been acknowledged for this 
>> connection. It is initialized to 68 (the minimum IPv4 MTU) when the
>>  underlying internet protocol is IPv4, and is initialized to 1280 
>> (the minimum IPv6 MTU) when the underlying internet protocol is 
>> IPv6.  Whenever an acknowledgement for a packet larger than 
>> maxsizeacked octets is received, maxsizeacked is set to the size of
>>  that acknowledged packet.
> 

Correct. The worst-case scenario is that you do the "path mtu update
phase" rather than "initial path mtu discovery". i.e., the mechanism
fails on the safe side.

>> constant.  MAXSEGRTO could be a function of the Next-Hop MTU 
>> claimed in the received ICMP "Packet Too Big" message.  That is, 
>> higher values for MAXSEGRTO could be imposed when the received ICMP
>>  "Packet Too Big" message claims a Next-Hop MTU that is smaller
>> than some specified value.
> 

They use a MAXSEGRTO of 1. I wrote and commited the OpenBSD
implementation myself. NetBSD ported the one in OpenBSD to their OS, so
they use the same MAXSEGRTO.

>> Section 7.3 shows the proposed counter-measure in action. Section 
>> 7.4 shows the proposed counter-measure in pseudo-code.
> 

I can, and I will. However, I think this has been overstressed for this
I-D. It's an Informational I-D. So it should be clear from the target
itself and the Page-1 boilerplate to be used for the RFC that it does
not contain any "formal IETF recommendation".

Thanks,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Jan 2010 23:08:34 +0200

Hi,

> works, I'd argue that for many of us the pseudo-code ends-up being a

I'm not arguing that it's clearer, I'm saying that this level of details seems unnecessary for an Informational document.

> since that, an plenty of revisions since then. And the I-D has passed WGLC.

So you're saying I should have flagged this earlier. And I probably should have. But now I'm re-reviewing the document during AD Review, and I felt this was an issue, so I'm raising it.

> Are we kinda going back to WGLC?

No, we're not. I do realize that the document has passed WGLC with these sections in it, so if the WG tells me "this is a conscious decision, we like this text to be in there" that's fine, but I want to make sure that that's the case and not "oh, actually, this is maybe an issue." (I know that passing WGLC in the current form is an implicit OK from the WG - I'm asking for an explicit one.)

> changing from std track to informational.

We did deliberate this for issue quite a bit, if I recall correctly. In the end, I think the WG felt that that the different implemented mitigation techniques had downsides that were too serious to go for PS.

(I'm not saying I necessarily agree with this sentiment, but I think that was the decision process.)

My comment was that the document might want to explicitly say this, so readers who might wonder why this isn't PS know.

> belonging to reality-based world.

I don't want to restart the Informational vs. PS discussion. The WG has decided that already.

> making documents irrelevant, rather than useful, to the reader.

I believe the WG consensus was to document and discuss the mitigation techniques that some stacks are using in this document. I don't believe the intent was to include a detailed technical specification and pseudo code for the mitigation techniques.

IMO, those are much more appropriate for a PS specification than an Informational document. If the WG wants to recommend these techniques as PS, then it should publish them as PS, and not via an Informational document that reads like a PS document.

> has produced, and has passed WGLC with this text in place.

I know. As I said above, I want to double-check that the WG is sure that this is what they want to publish.

> implementers, to get involved in the IETF process in general, and with

First, I strongly disagree that I'm ignoring WG consensus in any way. It is part of my duties as AD to review the documents that are coming out of a WG in my area for issues before I forward them to the IESG, because I will need to ballot Yes on them. I've done the review, found an issue, and am asking the WG for explicit feedback.

Second, please tell me in which case you believe that I have previously ignored WG consensus. You're making a very serious accusation here, so please back it up.

Lars

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 27 Jan 2010 15:35:08 -0600

This is as a WG participant, not a co-chair.  As some of
the document heritage predates me co-chairing, I'd have to
take a very careful look at mail archives and meeting
minutes in order to say anything about consensus in a
co-chair role.

That said ...

I would appreciate less posturing about representing vendors
and maintaining relevancy to them, and more focus on what
potential action we can take to resolve the DISCUSSes.

My contributions toward that are inline below.

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Fernando Gont
>Sent: Wednesday, January 27, 2010 3:21 PM
>To: Lars Eggert
>Cc: [email-masked] WG
>Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09
>
>

When I checked on this myself, it was indeed representing
what's been accepted into some implementations.

I believe Fernando has done the right thing at the beginning of
section 7.2 by mentioning right away that PLPMTUD eliminates
this vulnerability.  I did not really see strong WG consensus
as to whether PLPMTUD should be recommended more strongly as
a mitigation in lieu of the rest of section 7.2, 7.3, and 7.4,
and those sections do provide useful explanation and rationale
of what's been implemented, in my opinion.  I personally
think PLPMTUD is a much better thing to recommend, but see
the argument about convergence time may be valid, and the WG
didn't seem to express strong favor in either direction on this
matter.

*
However, Lars is entirely right that this could be worded more
clearly as an implemented behavior rather than a proposal that
we're making as the WG.  This was always the WG consensus of the
document's purpose, from what I can tell.
*

I think one way to proceed is, for instance, to reword:
"""
   Section 7.3 shows the proposed counter-measure in action.
   Section 7.4 shows the proposed counter-measure in pseudo-code.

   This behavior has been implemented in NetBSD [NetBSD] and OpenBSD
   [OpenBSD] since 2005.
"""
into:
"""
  Sections 7.3 and 7.4 show the behavior and psuedocode for the
  mitigation implemented in NetBSD and OpenBSD.
"""
and do a find-replace of the word "proposed" as appropriate in the
rest of the section in order to convey what we really mean: that
this is what's being done, not what TCPM necessarily says people
need to do.

>Are we kinda going back to WGLC?

I think Lars is just asking to quickly confirm consensus in this area
and make sure the exact text represents that consensus.

>good question, that not only me, but also vendors would like to know the

They are very much welcome to approach with a proposal to
standardize it ... however, they haven't so the topic is moot.
None of us need to try to channel them and speak for them here;
the list is open, and last I checked, there were hundreds of
addresses of the form "vendor.com" subscribed.

As RFC tracks are frequently misunderstood, the sentence Lars
proposes seems useful and uncontroversial to me.  I'm not sure
why we can't just add it as there's no harm done by it.

>belonging to reality-based world.

Veering off-topic ... can we table this type of discussion?  It's
not conducive to resolving the questions at hand.

>making documents irrelevant, rather than useful, to the reader.

I would agree with Fernando on this.  I expressed a similar
concern as Lars does a year or so ago, and there didn't
seem to be much significant feeling on this from the rest of
the WG.  As long as this material is hedged correctly as
explaining the implemented behavior, I think the WG consensus
of describing implemented behavior is met.  We are just
describing it in incredible detail rather than giving a
high-level view.  This is not necessarily bad, I think.

>implementers, to get involved in the IETF process in general, and with

Veering off track again ... please table this.

As mentioned above, I think if the section's content is hedged
correctly as describing the implementation that exists, rather
than a WG-proposed behavior, then we'll be within consensus.

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Jan 2010 14:13:19 -0800

Hi, all,

I'd like to second all of Wes's* points below.

I don't have a problem with including the code; it may be unnecessary,
but lots of informational docs have exactly that kind of detail to
explain things.

I do agree that it would be useful to avoid the term "proposed", as the
WG consensus as I recall it was to document what was implemented and
discuss the issues thereof, but not to make a recommendation.

I also agree with Lars's suggestion (and Wes's concurrence) that it
would be useful to be explicit in the fact that this doc does not make
such a recommendation.

I won't belabor other points below; I think Wes said it nicely.

Joe

-----

* PS - anyone have a good pointer to how to turn proper nouns that end
in 's' into possessive adjectives? I found a few, and at least one
suggests that "genitive of origin" always adds the 's' ;-)

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2010 19:34:46 -0300

Hello, Joe,

> discuss the issues thereof, but not to make a recommendation.

I agreed to remove any instances of "proposed" (Actually, I really meant
to eliminate them... it seems I just missed a few of them).

> would be useful to be explicit in the fact that this doc does not make

I have no problem with that, either. Would something like this text from
the soft-errors RFC address this issue?:

>    We note that the counter-measures discussed in this documentare not 
>    part of standard TCP behavior and this document does not change that 
>    state of affairs.  The consensus of the TCPM WG (TCP Maintenance and 
>    Minor Extensions Working Group) was to document this widespread 
>    implementation of nonstandard TCP behavior but to not change the 
>    TCP standard.

Note: I believe some of the countermeasures may be within the specs in
that they are reasons for not applying some of the "SHOULDs". But at
this point in time, I don't feel like committing yet more energy to
fight this one... so I'd be happy about including the above check.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Jan 2010 14:45:41 -0800

Fernando,

See below...

>>    implementation of nonstandard TCP behavior but to not change the 

Useful to fix the typo (documentare -> document are).

I prefer some of the text Wes provided. The text above just says "we're
not changing the spec". Wes had an additional tone of "and we aren't
even making any recommendations" (e.g., on how to interpret SHOULDs).

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 Jan 2010 08:26:52 +0200

Hi,

> suggested, and that didn't require further discussion).

I'll do the same in this reply.

> with the old boilerplate text.

Yes, but it's unlikely that the final revision will be submitted before Feb 1? IETF Last Call and IESG Review are still coming.

> in: http://www.gont.com.ar/advisories/index.html (and there are others).

But this is a TCPM WG document, and it was your personal involvement that caused the changes, and not the TCPM WG document. So it wasn't "this analysis" in the sense of this document, but "an analysis done by someone who now happens to be editor of the WG document."

> corporate network that is not connected to the Internet.

So that by "internet" you mean "IP-based isolated network" was completely lost on me. Is this really an important point? Why wouldn't a technique for this that works on the Internet work for isolated deployments? And if it does, why don't you simply say "Internet"?

> Would you be happier with "increased interrupt and context-switching rate"?

I'd just talk about increased processing overheads, but this isn't a terribly important issue.

> Therefore, it does not necessarily eliminate this vulnerability.

OK, but then say this in the document. It wasn't clear to me at all that you tried to allude to that by saying "would eliminate."

> phase" rather than "initial path mtu discovery". i.e., the mechanism

Let's discuss this for a second to make sure I understand this correctly.

The definition for acked_packet_size is: "Variable holding the packet size (data, plus headers) the ACK that has just been received is acknowledging." But that's actually not accurate, because an incoming ACK doesn't ACK a specific transmitted segment - all you know when you receive an ACK is that the left edge of the window moved by a certain amount. Is acked_packet_size simply set to that amount?

If yes, then with delayed ACKs (or otherwise in corner cases) acked_packet_size is actually larger than maxsizesent always. On second reading, I don't think that's a problem for the technique, but the name and description of the variable confused me earlier.

> they use the same MAXSEGRTO.

I forgot to say in my original comment that that may be interesting information to put in the draft, for readers who are wondering.

> not contain any "formal IETF recommendation".

Not all readers know the differences between different types of RFCs, and I'd prefer if the wording in the text was consistent with the message that the WG wants to send about these mitigation techniques.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 Jan 2010 08:29:31 +0200

On 2010-1-27, at 23:35, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> and more focus on what

Quick clarification: Those are obviously not IESG Review discusses, as the document is still in AD Review. I just used the same term in my review to indicate that I saw those as more important to discuss than maybe some of the other ones.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jan 2010 18:43:19 -0300

Hello, Lars,

>>> You're using the IETF Trust Provisions' Section 6.b License
>>> Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec
>>> 2009.  (See http://trustee.ietf.org/license-info/)
>> There was no way (other manual) to fix this (at least when the last
>> rev of the document was published). That said, the "grace period"
>> announced by the IETF Trust still lasts till February 1st, so
>> there's no problem with the old boilerplate text.
> 
> Yes, but it's unlikely that the final revision will be submitted
> before Feb 1? IETF Last Call and IESG Review are still coming.

Hopefully by that time xml2rfc will already support the new boilerplate?
Or, if anybody can provide the correct boilerplate, I could manually
edit the I-D.

>> No, I meant what I wrote: Those implementations that already
>> included the hard_errors -> soft_errors processing did so for the
>> same reason stated in the draft (e.g., I did talk with Kirk
>> McKusick back in 2005 and these guys (and others) got to the same
>> conclusion (e.g., hard-errors -> soft-errors) through the same
>> analysis). That said, other implementations implemented this in
>> response to this I-D (e.g., Cisco, Microsoft, and others). Please
>> see the "ICMP attacks" advisories linked in:
>> http://www.gont.com.ar/advisories/index.html (and there are
>> others).
> 
> But this is a TCPM WG document, and it was your personal involvement
> that caused the changes, and not the TCPM WG document. So it wasn't
> "this analysis" in the sense of this document, but "an analysis done
> by someone who now happens to be editor of the WG document."

I don't get your point. The BSD people implemented the hard_errors->
soft_errors thing as a result of the same reasoning that is included in
the icmp-attacks I-D. Other vendors applied this change in response to
this I-D. (For the most part, they don't care about the "individual
submission" vs. "wg item" thing, as you may have seen that they link the
document as http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html
which is supposed to always contain the latest revision).

I'm not sure if this serves as a data point, but: many vendors that have
a clue don't even care about the "Informational" vs. "bcp" vs. "std
track" vs. "individual I-D" vs. "wg item i-d" -- particularly when it
comes to security-related issues. It took us something like a year to
adopt this I-D as a wg item, and more than five years to get it
published as an RFC. Unless we do better time-wise, I'm afraid this
situation is unlikely to change (not that I'm happy about it).

>> I did mean "internet". The mechanism works if you're using it in
>> e.g. a corporate network that is not connected to the Internet.
> 
> So that by "internet" you mean "IP-based isolated network" was
> completely lost on me. Is this really an important point? 

No. I mean any network that uses IETF technology, no matter whether its
connected to the public Internet or not.

> Why
> wouldn't a technique for this that works on the Internet work for
> isolated deployments? And if it does, why don't you simply say
> "Internet"?

Because Internet implies "the Internet" (i.e., the public Internet).

>>> I thought most modern operating systems didn't use hard IRQs
>>> anymore in their stacks? Isn't it all soft-interrupts or similar
>>> now? (I do agree that packet processing overhead per payload byte
>>> goes up with smaller packets, but I don't think it's because of
>>> IRQs.)

Ok.

>>>>  "Packetization Layer Path MTU Discovery" that does not depend
>>>> on ICMP error messages.  Implementation of the aforementioned 
>>>> However, it might also lead to an increase of the PMTUD
>>>> convergence time.
>>> Add a citation to RFC4821 here. Also, why the conjunctive?
>>> PLPMTUD *does* eliminate this vulnerability.
> OK, but then say this in the document. It wasn't clear to me at all
> that you tried to allude to that by saying "would eliminate."

Ok. Will do.

>>>> On the other hand, maxsizeacked holds the size (in octets) of
>>>> the largest packet that has so far been acknowledged for this 
>>>> connection. It is initialized to 68 (the minimum IPv4 MTU) when
>>>> the underlying internet protocol is IPv4, and is initialized to
>>>> 1280 (the minimum IPv6 MTU) when the underlying internet
>>>> protocol is IPv6.  Whenever an acknowledgement for a packet
>>>> larger than maxsizeacked octets is received, maxsizeacked is
>>>> set to the size of that acknowledged packet.
>>> Maybe I'm dense, but how does this work with delayed ACKs? If you
>>> see the left edge of the window shift by n bytes, you don't know
>>> that maxsizeacked is n bytes, right?
>> Correct. The worst-case scenario is that you do the "path mtu
>> update phase" rather than "initial path mtu discovery". i.e., the
>> mechanism fails on the safe side.
> 
> The definition for acked_packet_size is: "Variable holding the packet
> size (data, plus headers) the ACK that has just been received is
> acknowledging." But that's actually not accurate, because an incoming
> ACK doesn't ACK a specific transmitted segment - all you know when
> you receive an ACK is that the left edge of the window moved by a
> certain amount. Is acked_packet_size simply set to that amount?

Yes.

> If yes, then with delayed ACKs (or otherwise in corner cases)
> acked_packet_size is actually larger than maxsizesent always. 

Well, that depends on the amount of data you send. But yes, you could
say that "acked_packet_size is actually larger than maxsizesent *usually*".

> On
> second reading, I don't think that's a problem for the technique, but
> the name and description of the variable confused me earlier.

Should I add a clarification?

>>>> MAXSEGRTO can be set, in principle, to any value greater than
>>>> or equal to 0.  Setting MAXSEGRTO to 0 would make TCP perform
>>>> the traditional PMTUD mechanism defined in [RFC1191] and
>>>> [RFC1981].  A MAXSEGRTO of 1 provides enough protection for
>>>> most cases.  In any case, implementations are free to choose
>>>> higher values for this constant.  MAXSEGRTO could be a function
>>>> of the Next-Hop MTU claimed in the received ICMP "Packet Too
>>>> Big" message.  That is, higher values for MAXSEGRTO could be
>>>> imposed when the received ICMP "Packet Too Big" message claims
>>>> a Next-Hop MTU that is smaller than some specified value.
>> implementation myself. NetBSD ported the one in OpenBSD to their
>> OS, so they use the same MAXSEGRTO.
> 
> I forgot to say in my original comment that that may be interesting
> information to put in the draft, for readers who are wondering.

Agreed. Will do.

>>> "proposed" something is slightly misleading. Can you rephrase
>>> this to be about what current implementations do?
>> I can, and I will. However, I think this has been overstressed for
>> this I-D. It's an Informational I-D. So it should be clear from the
>> target itself and the Page-1 boilerplate to be used for the RFC
>> that it does not contain any "formal IETF recommendation".
> 
> Not all readers know the differences between different types of RFCs,
> and I'd prefer if the wording in the text was consistent with the
> message that the WG wants to send about these mitigation techniques.

As I said, I have no problem with this. I will remove any remaining
instances of "proposed".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jan 2010 19:02:46 -0300

> potential action we can take to resolve the DISCUSSes.

FWIW, I'm not claiming to represent vendors. However, I do chat with
vendors from different fronts very often, and there is a general
agreement on each of the issues I mentioned (specifications being
outdated, the impossibility to produce a real-world TCP implementation
from the IETF specs, the unnecessarily huge amount of energy that is
spent on non-real issues, etc.).

At this point in time, I just want to get this document published. But
the points I have raised are very general issues that affect not only
this I-D, but many other I-Ds that this WG is working on.

Will do.

> and make sure the exact text represents that consensus.

I have not problem with that, but... isn't this what the WGLC is for?

> addresses of the form "vendor.com" subscribed.

This has been discussed in other threads and posts, so... in the hope of
keeping a good signal/noise ratio, I will not respond. :-)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jan 2010 19:13:49 -0300

Hello, Joe,

Will do.

> even making any recommendations" (e.g., on how to interpret SHOULDs).

Can you Wes provide the exact text you'd like me to include in the I-D,
so that we can finish this? :-)

Thanks!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2010 11:22:37 +0200

Hi,

> I'd be interested to hear the WG's thoughts esp. on this issue, but of course also on the rest of my comments below.

what I've heard so far from the WG is that the inclusion of those sections is desired, so I consider this issue resolved. I'll follow up to some of the other points I raised in another reply.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2010 11:32:08 +0200

Hi,

> Or, if anybody can provide the correct boilerplate, I could manually

see Alfred's email. There is a team forming to continue maintenance of xml2rfc, but esp. the testing and release handling remains an open issue.

> the icmp-attacks I-D.

Yes, but not because of the ID.

> Other vendors applied this change in response to
> this I-D.

That wasn't clear to me so far. Didn't you say earlier that you wrote those original techniques and got them merged? So essentially, it was actually that act that caused the ID to be written.

In any case: I think I've exhausted my powder on this smallish issue. I just wanted to make sure that the language in the draft reflects what actually happened.

> connected to the public Internet or not.

I never ascribed some sort of well-defined different between big-I and little-i Internet. If this is clear to everyone, leave it as-is.

> Should I add a clarification?

I think this would make sense. You might also want to change the name of the variable.

Lars