Subject: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and TCP's reaction to soft errors)

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Dec 2006 11:17:36 -0300

Folks,

I would like to state my opinion on the question asked by Mark (wrt 
what we would do with the ICMP docs if we were to take Matts 
suggestion for working on ICMP):

* Both of the drafts are aiming at Informational, thus just 
describing "what is implemented out there". No matter what we end up 
standardizing, that will not change what is currently implemented out 
there. That's one of the reasons for which I think that even if we 
got consensus to proceed as suggested by Matt, both documents should 
still be moved forward on the Informational path.

* In the case of the ICMP attacks draft, one of the goals of the 
document is to discuss ICMP-based attacks (other than "proposing 
mitigations). And many have argued that it is really needed (e.g., it 
is not clear to everybody how TCP MD5, IPsec, etc, interact with ICMP 
and TCP... and that's one of the things the draft tries to clarify).

* There are already a few RFCs, around ten internet drafts (including 
one by the IAB), and a few papers referencing it, and it is worth 
noting that while we have two documents on TCP-based spoofing attacks 
(antispoof and tcpsecure), if we were to drop the ICMP attacks draft 
we would end up having no doc describing ICMP attacks against TCP 
(which, ironically, are simpler than their TCP-based counter-part).

* Another thing with the ICMP attacks draft is that it describes 
quite a few mitigations that have been widely implemented, and not 
just the TCP SEQ check and that of dropping ICMP SQ. Therefore, even 
if we were to pull the ICMP SQ and the TCP SEQ check stuff from the 
document, there's still more stuff in the document that makes the 
draft worth publishing.

* I agree that the ICMP attacks draft needs more work. In the last 
few revisions I have been addressing lots of technical comments 
posted by many of you on the list. That's why I have not yet 
completely tackled those parts of the draft that are still "too 
prescriptive". This is going to be the goal of the next revision 
which, in the event anybody sends text (it's a wg doc!), will 
probably converge even sooner than expected.

* In the case of the ICMP soft errors draft, we have had discussions 
for the last two years, and we didn't get consensus to standardize 
the "abort the connection reset upon receipt of an ICMP soft error". 
But there are many implementations that already perform some 
alternative reaction to ICMP error messages received during the 
connection-establishment phase. I think we had already got consensus 
to document it. And the draft is very close (if not already) for WGLC 
(we bounced the doc a few times with Mark, and I will be able to 
publish a revision anytime soon).

* It is worth noting that we were recently talking about how to 
encourage participation of open source projects in the IETF. The ICMP 
attacks draft has benefited from the feedback of all major open 
source OSes, along the two years it has been around. While we 
certainly should not make a decision based exclusively on this point, 
I'm not sure all those guys would be happy to provide feedback on 
future drafts if they realize that the time they spent during two 
years contributing to an IETF doc basically ended up in nothing.

Kindest regards,

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Dec 2006 07:30:38 -0800

Fernando Gont wrote:
....
> attacks draft has benefited from the feedback of all major open source
> OSes, along the two years it has been around. While we certainly should
> not make a decision based exclusively on this point, I'm not sure all
> those guys would be happy to provide feedback on future drafts if they
> realize that the time they spent during two years contributing to an
> IETF doc basically ended up in nothing.

Perhaps knowing that "deploy widely first, document and validate later"
is not how the IETF works is appropriate feedback for that community,
esp. overzealous segments of it.

Joe

---

From: Andre Oppermann <[email-masked]>
Date: Thu, 07 Dec 2006 17:02:34 +0100

Fernando Gont wrote:
> Folks,
> 
> I would like to state my opinion on the question asked by Mark (wrt what 
> we would do with the ICMP docs if we were to take Matts suggestion for 
> working on ICMP):
> 
> * Both of the drafts are aiming at Informational, thus just describing 
> "what is implemented out there". No matter what we end up standardizing, 
> that will not change what is currently implemented out there. That's one 
> of the reasons for which I think that even if we got consensus to 
> proceed as suggested by Matt, both documents should still be moved 
> forward on the Informational path.

 From the point of view of an actual kernel and TCP/IP stack developer
I can only say that this documentation is invaluable for reference and
for interoperability issues.

In my opinion having this documented and preserved as an informational RFC
helps people new to TCP it to find it and to avoid the mistakes of the
past.  A new tcp/ip developer or hacker can avoid countless hours of
debugging and re-inventing the wheel by just looking at the work already
done for them by Fernando and all the other participants to it.  Not
formally documenting it would just let it slide into obscurity quickly
and in a year or two only us 'greybeards' will remember it while the next
generation repeats history again.  That's just wasteful.

This is a perfect application of the "standing on the shoulders of giants"
meme.

-- 
Andre (@FreeBSD.ORG)

> mitigations). And many have argued that it is really needed (e.g., it is 
> not clear to everybody how TCP MD5, IPsec, etc, interact with ICMP and 
> TCP... and that's one of the things the draft tries to clarify).
> 
> one by the IAB), and a few papers referencing it, and it is worth noting 
> that while we have two documents on TCP-based spoofing attacks 
> (antispoof and tcpsecure), if we were to drop the ICMP attacks draft we 
> would end up having no doc describing ICMP attacks against TCP (which, 
> ironically, are simpler than their TCP-based counter-part).
> 
> * Another thing with the ICMP attacks draft is that it describes quite a 
> few mitigations that have been widely implemented, and not just the TCP 
> SEQ check and that of dropping ICMP SQ. Therefore, even if we were to 
> pull the ICMP SQ and the TCP SEQ check stuff from the document, there's 
> still more stuff in the document that makes the draft worth publishing.
> 
> * I agree that the ICMP attacks draft needs more work. In the last few 
> revisions I have been addressing lots of technical comments posted by 
> many of you on the list. That's why I have not yet completely tackled 
> those parts of the draft that are still "too prescriptive". This is 
> going to be the goal of the next revision which, in the event anybody 
> sends text (it's a wg doc!), will probably converge even sooner than 
> expected.
> 
> * In the case of the ICMP soft errors draft, we have had discussions for 
> the last two years, and we didn't get consensus to standardize the 
> "abort the connection reset upon receipt of an ICMP soft error". But 
> there are many implementations that already perform some alternative 
> reaction to ICMP error messages received during the 
> connection-establishment phase. I think we had already got consensus to 
> document it. And the draft is very close (if not already) for WGLC (we 
> bounced the doc a few times with Mark, and I will be able to publish a 
> revision anytime soon).
>

---

From: Mark Allman <[email-masked]>
Date: Thu, 07 Dec 2006 11:49:43 -0500

Thanks for the thoughts folks.  Let me try to ask a more refined
question rather than the pretty open question I asked last night.

What I am really wondering about still is how Matt's vision encompasses
or does not encompass the two current work items.  In other words, in
abstract terms if we were going to write one document that said "people
do X" without making a recommendation or changing a standard and then we
wrote something else that standardized X as OK (SHOULD, MAY, whatever
...) then these would be largely overlapping efforts and we might decide
that doing both would be silly.

So, it seems to me that we have some WG consensus to take on two tasks.
Therefore, I think Andre's point is covered.  We will get this
information written down.  But, I do not think the consensus to work on
these items says precisely how to accomplish that task.  What I am
trying to understand is how the current documents overlap with Matt's
vision.  Will the documents Matt proposes naturally include the
information in the two current documents?  Will there be missing pieces
that we need to pick up (here or in tsvwg or wherever)?

Matt- can you help me?

Thanks!

allman

---

From: Lars Eggert <[email-masked]>
Date: Thu, 7 Dec 2006 18:11:29 +0100

On Dec 7, 2006, at 17:49, Mark Allman wrote:
> these items says precisely how to accomplish that task.

I think there is value in writing down what is currently implemented,  
with a statement big red letters that says:

    1. the purpose is documentation
    2. the mechanisms have not undergone IETF review
    3. the mechanisms are not IETF standards
    4. the IETF may develop standards-track mechanisms that may differ
       from what is described here

Once we have (4), that should informatively cite the informational  
documents to "obsolete" them.

>   What I am

I see the informational documents and Matt's proposal as (almost)  
orthogonal. One says what is currently out there. The other says what  
_should_ be out there. Parts may be identical (parts of what's out  
there is what should be out there), but other parts may differ.

What is important is to not confuse the informational documents for  
the (non-existing) standards-track ones, and word them in a way that  
makes this distinction clear.

Lars

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Dec 2006 15:46:51 +0200 (EET)

> generation repeats history again.  That's just wasteful.

I fully support this view.  The ICMP soft-errors and attacks 
(preferably, all of it; splitting up just takes energy and will take 
more time) needs to go out, sooner the better.  This has already 
dragged on too long (years).

More general standards track work on ICMP will be of longer timescale 
(just to get agreement on the right approach and to get the details 
right will take a number of years), hence it should not block work 
that has been going (and implemented) for years.

Unified ICMP work should happen in TSVWG or in a new WG.  To gauge 
community interest (and tentative consensus) on this, it might not be 
a bad idea to organize a BoF on the topic (not necessarily aimed at 
creating a new WG).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Matt Mathis <[email-masked]>
Date: Fri, 8 Dec 2006 09:59:21 -0500 (EST)

Sorry, Matt hasn't decided what his vision encompasses...

My plan (for me) is to re-read all of the recent material, and try to assemble
a "master outline" of everything that I think we need to consider including in
some future ICMP document.

I would like to reuse as much of Fernando's text as possible, but probably
reorganized into different documents.

Publishing "as built" documents is generally a good thing, especially if they
can be viewed as prototypes of future standards.  However some cases are not
good, such as if they cause implementers to invest in code that is not part of
the correct solution.   I don't think that is the case here.

But I don't have my head around enough of the problem yet.

One thing that would be a huge help - if somebody could start on an
inventory/bibliography of all RFC's that mention ICMP.

This will become one section of either the principles document, or a
non-RFC-track planing doc, and then eventually the basis for the "All ICMP
updates doc"  This bibliography is critical to understanding the big picture.

RFC number:
Title:
RFC status: (std/informational/obsolete, etc)
Extent of ICMP language: (incidental, significant, primary)
     (Extent which the RFC is about ICMP vs some other protocol)
Protocols: ICMPv4, ICMPv6, both
ICMP types mentioned: echo, redirect, etc or classes such as "errors"
ICMP roles: generation, reaction, request/response, translation/conversion, other

For the first pass, I just need to know about RFCs that are current standards
or standards track.   We eventually need to do this for all non-obsolete RFC
and all mature ID's.....

Fernando, are you up to this task?

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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Dec 2006 08:27:41 -0800

FWIW, my take is that there is value in documenting
operational issues for ICMP as informational in the
near term - or, at least having an agreed-upon plan
of action for moving forward. We already have RFC2923
and possibly others as useful examples that document
as informational certain operational aspects of ICMP.

The other thing to consider is that the operational
issues would not go away were we to decide to abandon
efforts; the subject would simply come around again
at some later point in time.

I don't care so much what form the documentation
takes or where the work is done, but if there are
operational issues and we already have a good head
start on understanding them, why not see the work
through to a useful conclusion?

Thanks - Fred
[email-masked]

---

From: Mark Allman <[email-masked]>
Date: Fri, 08 Dec 2006 16:23:34 -0500

> My plan (for me) is to re-read all of the recent material, and try to
> assemble a "master outline" of everything that I think we need to
> consider including in some future ICMP document.

Thanks.  That would be very useful.

allman

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Dec 2006 22:25:04 -0300

>updates doc"  This bibliography is critical to understanding the big picture.
[....]
>Fernando, are you up to this task?

Yes.

As you mentioned, I will start with the std track RFCs, and will try 
to get the document ready ASAP. From then I will move on.
Do you think we should go through all the RFCs (i.e, std track and 
non-std track), and then move on to the ID's, or go through the std 
track RFCs, then through the IDs, and then through the rest of the RFCs?

Kindest regards,

---

From: Matt Mathis <[email-masked]>
Date: Sat, 9 Dec 2006 15:50:55 -0500 (EST)

Well, there is not much point in going through deprecated and other obsolete
RFC's.  I think we should at least know about Informational RFC's that mention
ICMP.

What tools have you been using for version control and formatting you ID's?

Thanks,
--MM--

---

From: [email-masked]
Date: Sat, 9 Dec 2006 20:16:27 -0300 (ART)

Matt,

> Well, there is not much point in going through deprecated and other
> obsolete RFC's.

Yep. I was meaning Informationals.

> I think we should at least know about Informational RFC's that
> mention ICMP.

Okay. Will first go through the std track ones, then through the
Informtionals.

> What tools have you been using for version control and formatting you

I use the online tools at http://xml.resource.org.

Kindest regards,
Fernando Gont