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

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 14 Dec 2006 07:22:09 -0800 (PST)

Hi, 

I looked up the following e-mail from Adrian in the mail archives. As someone
that used open source code and responsible for the development of security
appliances, I would fully support and second Andre Opperman's view. Fernando
did a great job of uncovering the problems in ICMP that have been nascent for
years. Having the problems and their current solutions formally documented as
RFCs is a boon to to the current and future developers.

Having the two ICMP docs formally published as RFCs is also immensely valuable
to the current and future IETF contributors. I am a co-author of two Behave WG
documents - TCP-Behave and ICMP-behave. Both of the Behave drafts refer
Fernando's ICMP docs.

I support forwarding both documents as RFCs at the earliest. Thank you.
 
regards,
suresh
 
----------------------------------------------------------------------------
> 
> To: Fernando Gont <fernando at gont.com.ar> 
> Subject: Re: [tcpm] Future of the ICMP docs (ICMP attacks against TCP and
> TCP's
> reaction to soft errors) 
> From: Andre Oppermann <andre at freebsd.org> 
> Date: Thu, 07 Dec 2006 17:02:34 +0100 
> Cc: tcpm at ietf.org, tsv-dir at ietf.org 
> 
>
--------------------------------------------------------------------------------
> 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)
> 
> 
> * 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: fernando at gont.com.ar || fgont at acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 

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