Re: [tcpm] tcp-security: More feedback requested for the documentoutline
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tcpm] tcp-security: More feedback requested for the documentoutline
I think since this is primarily for developers the current outline is slightly better then Joe's suggested outline.
(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia
> -----Original Message-----
> From: tcpm-bounces at ietf.org [mailto:tcpm-bounces at ietf.org] On
> Behalf Of Joe Touch
> Sent: Wednesday, September 09, 2009 12:18 AM
> To: Fernando Gont
> Cc: tcpm-chairs at tools.ietf.org; tcpm at ietf.org
> Subject: Re: [tcpm] tcp-security: More feedback requested for
> the documentoutline
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Fernando Gont wrote:
> > Folks,
> >
> > The original deadline for commenting on the document
> outline is over.
> > These are the comments so far:
> >
> > * Joe: wants to change the outline from the current outline (which
> > basically analyzes TCP on a "per-protocol-field",
> > "per-protocol-mechanism" basis, etc.) to an outline that basically
> > analyzes TCP on a "per-attack" basis (his proposal is available at:
> > http://www.ietf.org/mail-archive/web/tcpm/current/msg04838.html)
>
> The outline I proposed breaks things down into groups based on:
>
> control plane in-band
> control plane out-of-band
> data plane
> API
>
> This is (loosely) based on how TCP is specified (order not
> withstanding).
>
> Although I did suggest talking about attacks first, then talking about
> mitigations (to separate the two, because a single attack can have
> multiple mitigations, and a single mitigation can inhibit multiple
> attacks), the overall structure is not per-attack as much as
> it based on
> breaking the protocol down into its component parts.
>
> - ---
>
> It also distinguishes between protocol weaknesses (places where the
> protocol creates a vulnerability, regardless of implementation - e.g.,
> ICMP attacks), implementation choice issues (places where a
> choice left
> to implementers can cause problems if poorly chosen - e.g., how some
> SHOULDs turn into "don't do this in a secure implementation"), and
> implementation vulnerabilities (implementation issues not related to
> choices in the spec that create problems - e.g., searching
> the TIME-WAIT
> list linearly).
>
> Regardless of how we proceed, I believe that this latter
> issue should be
> considered in the presentation of solutions.
>
> > * Wesley: would like to change the outline as proposed by
> Joe, but could
> > live without doing that.
> >
> > * Alfred: wants to leave the outline as is
> >
> > * Fernando: wants to leave the outline as is
> >
> > * Toby: wants to change the outline as proposed by Joe
> >
> > I don't personally see clear consensus for changing the
> outline (even
> > less if we consider that many more people had agreed to accept the
> > document "as is").
> >
> > However, as there have not been that many opinions about
> the outline, I
> > think it would be a good idea if wg participants that have not yet
> > voiced their opinion regarding the document outline have
> another chance
> > to do it.
> >
> > So let's set a new deadline for this second round
> off-comments: if you
> > have any comments regarding the document outline, please voice your
> > opinion till September 16th (Wednesday), 2009.
> >
> > Thanks!
> >
> > Kind regards,
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqnSJEACgkQE5f5cImnZrvSDACg07iCr3uC1ORZ8rvT3PWYrbmq
> yDYAoKzt6bDekRm6c5HLvgmDVenPW2m1
> =Qg/w
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.