Subject: [tcpm] Unified ICMP processing: A straw man

From: Matt Mathis <[email-masked]>
Date: Fri, 1 Dec 2006 14:43:29 -0500 (EST)

After several side conversations about the state of ICMP, I decided to try to
distill my views down to a fairly crisp argument about how ICMPv4 and ICMPv6
should be uniformly processed by all protocols.  There is some evidence that
as a community we are already drifting in the direction described below,
although not in a very coordinated manner.  I would like to test the
possibility of finding consensus, loosely based on the following ideas:

ICMP should never be mandatory for correct protocol operation.  This is now
possible because the new path mtu discovery is nearly done.  It is desirable
to make ICMP work as well as possible because it makes all protocols
"friendlier" in the presence of assorted problems.

It is risky and undesirable for the default response to any unauthenticated
message from the network to be to abort a connection, no matter what the
protocol state.  Given this, we would like invent appropriate soft error
actions for all current hard errors. (And to deprecate the distinction, as
has already been done in RFC4443.)

If we do this well enough, there is no point in offering the configuration
option to abort connections because it just isn't needed.

For most protocol states, the right action is to cache ICMP error codes and
use them to embellish messages associated with connection timeouts or other
events.

In some protocol states it is appropriate for ICMP messages to accelerate
protocol timers.  However we should not assume the details to be self
evident.  They should be explicit, per protocol.

For example it would be appropriate for ICMP unreachable messages reduce TCP's
connection timeout from ~2 minutes to a few seconds.  However this MUST be
configurable.

When trying to establish a connection to a node which has multiple addresses
(or multiple possible protocols or paths, etc) it is appropriate for ICMP
unreachable messages to shorten the headway timer between attempts to
successive addresses.  I used to think the correct way to do this is to abort
earlier connection attempts, but I have recently change my mind: all
connection attempts should proceed in concurrently, and the first successful
connection should abort all incomplete connections.  (I know the common APIs
can't implement this, but the standard should describe the preferred
behavior).

Likewise an "ICMP redirect" could be treated like a routing soft error, and be
used to wake some sort of "router discovery" daemon to decide if there is an
actionable routing problem.  BTW some time ago (10 years?)  there was an
extensive discussion about tightening the consistency checks for ICMP
redirects.  (Something to the effect that the from-address for the ICMP should
match the actual next hop IP address used by this connection.)  Was this ever
published as an RFC?  Can anybody recall when this conversation happened and
which IETF list?

All layer 4 protocols have the option to apply protocol specific consistency
checks to ICMP messages.  The SCTP cookie is probably sufficient
authentication justify aborting connections.  But this is based on some
assumptions about on-path vs off-path attacks.

The TCP sequence check may also be applied.  Note that in general this is not
sufficient authentication to justify aborts.   Although I agree with Joe
that it is a layer violation in a strict sense, I point out that TCP is
loaded with heuristics designed to glean network state from subtle signals.
My objection is to prescribing TCP sequence checks as a first line of defense,
beyond the true robustness and strength of the technique.  It is cheap and
easy to implement and helps greatly if there are no other defenses.

Other techniques can be applied: e.g. keeping all transmitted headers for some
time interval, and matching the entire immutable portion of the header
including IP ID, transport checksum etc - expensive but pretty robust against
off-path attacks.  This can even be applied to encrypted payloads, and may be
a desirable techniques in some environments.  I would consider modeling all
upper layer ICMP consistency checks as optimizations on full header matching.

Also note that this really calls into question some of our assumptions about
on-path vs off-path attacks.  One possible approach would be to make ICMP
completely tolerant to on-path attacks by making all ICMP reactions totally
"soft": an attacker could cause incorrect error messages, but could not
interfere with correct protocol operation, unless the attacker could prevent
the delivery of legitimate protocol messages.  This approach makes all
forms of header matching considerably less valuable.

These comments were intended to be protocol independent.  Please excuse me if
I have messed up some of the details.

--------------------------------------------------------------------------
So what next?

Here is an updated straw man plan that I suggested to a smaller group:

In tcpm: Finish an Informational RFC on TCP sequence checks based on the
attacks draft.   Must be in the tone "this is how one implementor choose to do
it".  Must not over represent the strength or value of the defense.

Also in tcpm: a quick draft to deprecate responding to source quenches, and
possibly tweak some other details.

In tsvwg: introduce a problem statement/principles) draft, to cover the
following topics:
 - State some goals:
        review and unify ICMP processing across all protocols
        rationalize how ICMP fits into 7 layers (?)
 - Inventory the problem
	Observe that most ICMP specifications are adjunct to other protocols
        There are ~490 RFCs (and 200+ IDs) that reference ICMP
        Need some analysis and a plan here
 - Possible philosophical direction (Follow the general points above):
        All ICMP should be advisory
        Loosing ICMP should never be fatal
        ICMP messages should be cached for upper layers to consult as needed
        In some cases ICMP accelerates protocol timers
        Add per protocol validity checking where it makes sense
        ICMP should fit into (or prototype) a good interlayer message
          model for general event notification(?)

A follow on "Unified ICMP" document would replace the relevant sections in
RFC1122, "host requirements", (section 3.2.2 "ICMP" and 4.2.3.9, "TCP response to ICMP
messages") and perhaps (sections of) other key documents.  This would probably
be in tsvwg, with input from tcpm.  It may need to be be more than one
document.

Draft a "ICMP Updates" document that would amend or validate all standards
track documents that mention ICMP, to bring everything into conformance with
the new Unified ICMP spec.

---------------------------------------------------------------------------

This is a huge among of work, and is not going to converge unless we can get
at least some initial consensus on the key technical points.

At this stage I am mostly interested to know if there are substantial
disagreements with my technical observations. If there is basic technical
agreement the plan will work itself out.

What do people think?  Have I missed anything major?  Am I way off base on
anything?   Are my ICMP principles sound?

Thanks
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Thomas Narten <[email-masked]>
Date: Sun, 03 Dec 2006 08:42:23 -0500

Hi Matt.

Thanks for this note. I think this is an interesting and probably
inevitable way we should evolve with ICMPs. And I'm generally in favor
of trying to unify and pull together the overall thinking of where we
are at with ICMP.

On one specific point...

Matt Mathis <[email-masked]> writes:

> Likewise an "ICMP redirect" could be treated like a routing soft
> error, and be used to wake some sort of "router discovery" daemon to
> decide if there is an actionable routing problem.  BTW some time ago
> (10 years?)  there was an extensive discussion about tightening the
> consistency checks for ICMP redirects.  (Something to the effect
> that the from-address for the ICMP should match the actual next hop
> IP address used by this connection.)  Was this ever published as an
> RFC?  Can anybody recall when this conversation happened and which
> IETF list?

FYI, IPv6 does this. From RFC 2461:

> 8.1.  Validation of Redirect Messages
> 
>    A host MUST silently discard any received Redirect message that does
>    not satisfy all of the following validity checks:

...

>       - The IP source address of the Redirect is the same as the current
>         first-hop router for the specified ICMP Destination Address.

Thomas

---

From: Fernando Gont <[email-masked]>
Date: Sun, 03 Dec 2006 14:23:45 -0300

Matt,

I agree with most of the technical comments in your e-mail. Regarding 
the plan, my view is the following:

There's currently two drafts in the tcpm wg that are aiming at 
Informational. One describes the problem of long delays between 
connection-establishment attempts (draft-ietf-tcp-soft-errors) and 
the other one describes the issue of ICMP attacks against TCP. These 
two docs are meant to describe what the industry has done on the 
subject (and, FWIW, have received lots of feedback from open source OSes).

My view is that these two docs should be moved forward (on the 
Informational path). They document what the industry has done, and 
have been of help to quite a bunch of documents (referenced in a few 
RFCs, about ten IDs (including one by the IAB), and a few papers on 
the subject). FWIW, I believe the soft errors draft is ready for WGLC 
(there's a revision to be posted soon)... The ICMP attacks draft 
needs to be tweaked, as it is still too prescriptive, but that's what 
the focus of the next revision would be on.

At the same time, I think we should be doing the plan you suggest. 
When making actual changes to the standard, both of the icmp docs 
(icmp attacks and tcp soft errors) will probably be good Informative 
references.

I wouldn't object, though, to pull the TCP SEQ and the ICMP SQ stuff, 
and make them the two drafts you mentioned in your plan, while 
keeping a brief discussion about the tcp seq and ICMP SQ in the icmp 
attacks draft. (BTW, you mention that they should be 
"Informational"... however, I'd probably aim at std track).

No need to say, I volunteer to work on the docs you proposed in your 
plan, and help to push the "Unified ICMP" idea move forward.

Kindest regards,
Fernando Gont

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

---

From: Matt Mathis <[email-masked]>
Date: Tue, 5 Dec 2006 20:06:00 -0500 (EST)

I have recived zero negative responses and just a few positive responses to
my "straw man" message.  I would like to amend my request:

If you think my technical points are correct and would like to see this
pursued in tcmp and tsvwg, please speak up.    (But go easy on the list).

Thanks,
--MM--

---

From: Ted Faber <[email-masked]>
Date: Wed, 6 Dec 2006 14:56:32 -0800

> pursued in tcmp and tsvwg, please speak up.    (But go easy on the list).

I think these things.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Dec 2006 15:04:26 -0800

I think your techical points are correct, but I have
no opinion on the forum where they should be pursued. 

-----Original Message-----
From: Matt Mathis [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 5:06 PM
To: TCP Maintenance and Minor Extensions WG
Cc: [email-masked]
Subject: [tcpm] TAKE TWO: Unified ICMP processing: A straw man

I have recived zero negative responses and just a few positive responses
to
my "straw man" message.  I would like to amend my request:

If you think my technical points are correct and would like to see this
pursued in tcmp and tsvwg, please speak up.    (But go easy on the
list).

Thanks,
--MM--

---

From: David Borman <[email-masked]>
Date: Wed, 6 Dec 2006 17:28:37 -0600

Yes, I think this should be pursued.  Probably this should be in  
tsvwg, not tcpm, even if TCP is the motivation for doing the work.  I  
also view this in at least two distinct parts that are somewhat  
orthogonal to each other.

First, when an ICMP packet arrives, do I believe that it is a  
legitimate ICMP packet?  How do I go about checking the packet?  How  
should hosts/routers generate ICMP messages?  (Mostly a question of  
how much of the original packet do you return).  What sort of checks  
are generic at the IP/ICMP layer?  What additional checks/ 
verifications do the upper level protocols use when the ICMP message  
is delivered to them?

The second category is now that I have an ICMP packet and I've  
decided that it is legitimate (to some degree), how seriously do I  
take it?  Is it a hard error, or just a suggestion of something that  
might be wrong?  Do I drop connections based on this?

Believing that an ICMP packet is legitimate is probably not a yes/no  
answer, it will probably have shades of gray.  If so, that would then  
become part of the input to the second category.

I think it'll be a lot easier to get something written if issues are  
categorized into one of these two areas, and we avoid mingling them  
as much as possible in the document.

			-David

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Dec 2006 19:47:44 -0800

Matt Mathis wrote:
> pursued in tcmp and tsvwg, please speak up.    (But go easy 

I think some of the points are correct, but others have far-reaching
ramifications. If all ICMPs are advisory, e.g., then some things we rely
on for correct operation would silently fail (redirects, in particular).

Also in particular, sequence checks on ICMPs to transport protocols may
make sense, BUT the question is "what is the window". Unack'd data is
not appropriate; meaningful messages can take longer than that to be
received, since ICMP is a slow-path mechanism. The real question is
whether there is a meaningful window - other than 'anywhere' - that can
be specified.

Overall, I'm not sure an absolute approach is feasible.

If pursued, given the ramifications to so many protocols (transport,
network, and routing), this is beyond TSVWG, but might be appropriate
for IntArea to create a WG for.

Joe

---

From: Mark Allman <[email-masked]>
Date: Wed, 06 Dec 2006 23:10:33 -0500

[TCPM WG co-chair hat OFF.]

> I have recived zero negative responses and just a few positive
> responses to my "straw man" message.  I would like to amend my
> request:
> 
> If you think my technical points are correct and would like to see
> this pursued in tcmp and tsvwg, please speak up.  (But go easy on the
> list).

I like your straw man and generally support it (meaning, I might quibble
here and there, but think that it is significantly the right path).

allman