Re: [tcpm] [OPSEC] draft-gont-tcp-security
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tcpm] [OPSEC] draft-gont-tcp-security
- To: Todd Glassey <tglassey at earthlink.net>
- Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security
- From: Lars Eggert <lars.eggert at nokia.com>
- Date: Wed, 15 Apr 2009 10:17:19 +0300
- Cc: "'tcpm at ietf.org'" <tcpm at ietf.org>, "'ietf at ietf.org'" <ietf at ietf.org>, Joe Touch <touch at ISI.EDU>, "Smith, Donald" <Donald.Smith at qwest.com>, 'Joe Abley' <jabley at ca.afilias.info>, "'opsec at ietf.org'" <opsec at ietf.org>, Fernando Gont <fernando at gont.com.ar>
- Delivered-to: tcpm at core3.amsl.com
- In-reply-to: <49E4E233.9040609 at earthlink.net>
- List-archive: <http://www.ietf.org/mail-archive/web/tcpm>
- List-help: <mailto:tcpm-request@ietf.org?subject=help>
- List-id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
- List-post: <mailto:tcpm@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
- References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8 at NDJSSCC01.ndc.nasa.g ov><49E36AB9.40507 at isi.edu> <49E384E9.1050106 at gont.com.ar><49E3878C.9080200 at isi.edu> <49E39119.1060902 at gont.com.ar> <B01905DA0C7CDC478F42870679DF0F1004BC4176D0 at qtdenexmbm24.AD.QINTRA.COM> <49E3A88F.9060301 at gont.com.ar> <49E3ABC0.1050601 at isi.edu> <49E3B9BF.1060901 at gont.com.ar> <49E3BED9.1030701 at isi.edu> <C9E987CC-0213-4C67-BA0A-11C736772EE7 at nokia.com> <49E4D257.40504 at gont.com.ar> <49E4E233.9040609 at earthlink.net>
Hi, Todd,
On 2009-4-14, at 22:21, Todd Glassey wrote:
Fernando Gont wrote:
Lars Eggert wrote:
I agree with Joe that some of the hardening techniques that
vendors are
implementing come with consequences (make TCP more brittle). To
me, this
is a *reason* this document should be published via the IETF (i.e.,
TCPM) - we are probably in the best position to correctly evaluate
and
classify the impact of various hardening techniques. Stack vendors
have
been putting these mechanisms in to their stacks without clear
specifications and discussions of the potential upsides and
downsides
that would let them make an educated decision. It seems clear to
me that
the vendor community is looking for guidance here, and I do
believe the
IETF should give it.
This is the reason for which the output of the CPNI project was
submitted as an IETF I-D.
Yeah - so then this would be tested across all of the local TCP
implementations including the MS, AT&T *(i.e. Lachman Associates Inc)
and possibly Mentat's fast system?
Nothing would be "tested", the IETF isn't in the business of auditing
TCP stacks. What we're talking about is describing attack vectors,
potential countermeasures and the the impact (downsides) those
countermeasures might come with. Implementors will need to decide for
themselves if and how to apply any of these techniques to their stacks.
Lars
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.