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.