From tcpm-bounces@ietf.org Mon Jul 03 05:14:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKVv-0004am-Na; Mon, 03 Jul 2006 05:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKVu-0004aV-CW for tcpm@ietf.org; Mon, 03 Jul 2006 05:14:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxKVr-0006Q2-HD for tcpm@ietf.org; Mon, 03 Jul 2006 05:14:42 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 02560500004 for ; Mon, 3 Jul 2006 11:14:39 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 11:14:38 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 11:14:38 +0200 Message-ID: <44A8DFFD.7080506@ericsson.com> Date: Mon, 03 Jul 2006 11:14:37 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/mixed; boundary="------------050806070205080309060700" X-OriginalArrivalTime: 03 Jul 2006 09:14:38.0594 (UTC) FILETIME=[1C17F620:01C69E81] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [tcpm] [Fwd: WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------050806070205080309060700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please respond with any comments to TSVWG Magnus Westerlund --------------050806070205080309060700 Content-Type: message/rfc822; name*0="WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW" >From - Thu Jun 29 06:11:31 2006 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 06:10:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69B32.04553180" Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw109.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 06:10:55 +0200 Received: from esealmw127.eemea.ericsson.se ([130.100.184.162]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 06:10:55 +0200 Received: from mailgw1.ericsson.se ([193.180.251.59]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 06:10:54 +0200 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id 69FD7792 for ; Thu, 29 Jun 2006 06:10:54 +0200 (CEST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2006 21:10:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5T4ArEW015733; Wed, 28 Jun 2006 21:10:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5T4Alkk024470; Wed, 28 Jun 2006 21:10:47 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 21:10:46 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 21:10:45 -0700 Return-Path: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-OriginalArrivalTime: 29 Jun 2006 04:10:46.0275 (UTC) FILETIME=[FF21DD30:01C69B31] X-Sender: jmpolk@email.cisco.com X-Brightmail-Tracker: AAAAAA== Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass (sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=605; t=1151554253; x=1152418253;c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20|Subject:WGLC=20for=20draft-ietf-tsvwg-tcp-mib-extension-10=20starts=20NOW;X=v=3Dcisco.com=3B=20h=3DNuSA5Vwvam205b194Q1WdJWoGgk=3D; b=N7MdZpcXtsGXQdLQBUI/6pNnhPrHo2jntCOeacBQ1MERoBGclblRIhXHxeFqSVeRPR/1hTubkwZ4wxY+t0rSO6N8g3xedTyRvVu0UhKqxDaaAOIZZmYEgRMx26J3Jij3; Content-class: urn:content-classes:message Subject: WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW Date: Thu, 29 Jun 2006 06:10:44 +0200 Message-ID: <4.3.2.7.2.20060628230353.040fdde8@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW Thread-Index: AcabMgSbWUFaF7ozQtyXa02FPkGBAw== From: "James M. Polk" To: "tsvwg" Cc: "Matt Mathis" , "Lars Eggert" , "Magnus Westerlund \(KI/EAB\)" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69B32.04553180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TSVWG Comments on draft-ietf-tsvwg-tcp-mib-extension-10.txt have been quite for a couple of months now, and it appears this is a = stable=20 document, therefore WGLC starts NOW (June 29th) ending in 14 days (July=20 13th), or when discussion of this document stops - whichever is later. All comments (nits, errors, suggestions, comments, approval) regarding = this=20 ID should be directed to the TSVWG list. The goal of this document is Standards Track, and it has already been=20 evaluated by the MIB folks, with suggestions incorporated. cheers, James Lars Magnus IETF TSVWG co-chairs ------_=_NextPart_001_01C69B32.04553180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW

TSVWG

Comments on

        = draft-ietf-tsvwg-tcp-mib-extension-10.txt

have been quite for a couple of months now, and it appears this is a = stable
document, therefore WGLC starts NOW (June 29th) ending in 14 days = (July
13th), or when discussion of this document stops - whichever is = later.

All comments (nits, errors, suggestions, comments, approval) regarding = this
ID should be directed to the TSVWG list.

The goal of this document is Standards Track, and it has already = been
evaluated by the MIB folks, with suggestions incorporated.
cheers,

James
Lars
Magnus
        IETF TSVWG co-chairs

------_=_NextPart_001_01C69B32.04553180-- --------------050806070205080309060700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------050806070205080309060700-- From tcpm-bounces@ietf.org Mon Jul 10 12:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyMJ-000575-Md; Mon, 10 Jul 2006 12:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyMI-00056o-5I for tcpm@ietf.org; Mon, 10 Jul 2006 12:11:42 -0400 Received: from [132.219.15.238] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzyMG-0001AZ-Nt for tcpm@ietf.org; Mon, 10 Jul 2006 12:11:42 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1259C1CC22 for ; Mon, 10 Jul 2006 09:10:48 -0700 (PDT) To: tcpm@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 10 Jul 2006 09:10:48 -0700 From: EKR Message-Id: <20060710161048.1259C1CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [tcpm] [Repost] Review of the various TCP MACing proposals X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I originally sent this to bts, but it should probably be posted here.... -Ekr BACKGROUND ---------- There's growing discomfort about the security of TCP MD5 [RFC 2385]. This discomfort comes from a variety of factors: 1. TCP MD5 is an old-style H(Data || Key) design rather than a more modern HMAC-style construction. 2. Recent work by Wang et al. has cast doubt on the security of MD5 in general and it may be applicable to this construction. 3. TCP MD5 doesn't support key rollover, which means that rekeying requires tearing down existing connections which is a problem for BGP. There has been a lot of discussion about what to do to correct these failings. One obvious strategy (though by far not the only one) is to produce an improved version of RFC 2385. This memo discusses three such proposals. draft-bellovin-keyroll2385-00 [Be06] draft-bonica-tcp-auth-04 [BWVLW06] draft-touch-tcpm-tcp-simple-auth-01 [TA06] Note that there are other architectural options, such as running everything over IPsec that are not discussed here. The intent is to discuss merely the proposals which have a lot of commonality. COMMON ISSUES ------------- A number of common issues come up here: - Use of key identifiers: One natural way to support key rollover is to incorporate a key (or association) identifier. This allows the receiving party to determine which key was used to protect the received segment. It also provides a potential hook for external key management, e.g., via IKE. - Trial Authentication: If multiple parallel keys are used for rollover and a key identifier is not used, then the receiver potentially needs to try all the available keys. Concerns have been raised about the potential for computation-based DoS in such systems. - Replacement of MAC algorithm: One way to address issues (1) and (2) above is to replace the current construction with a more modern one such as HMAC. There are actually two issues here, the construction and the underlying digest. draft-bellovin-keyroll2385-00 ----------------------------- This draft is only intended to address the key rollover problem. It is bits on the wire compatible with RFC 2385 and simply provides algorithms on the receiver and sender side for use and detection of new keys. No key identifier, so there is a potential for DoS as indicated above. The MAC algorithm is not replaced. Not replacing the MAC algorithm makes me fairly uncomfortable. The construction in RFC 2385 is almost certainly weak and is getting weaker as time goes on. If we're going to go to the trouble of doing anything I believe that we should replace the MAC algorithm with a more modern one. I'm also not sure I think that the receiver-side algorithm proposed here is the best choice, since it seems designed to allow the use of multiple keys more or less indefinitely (until the old one is expired) rather than having a clean cutover after which the old key is no longer accepted. ISTM that you could use TCP sequence numbers to determine a low-water mark after which the old key could no longer be used. draft-bonica-tcp-auth-04 ------------------------ This draft addresses both the key rollover issue and the MAC algorithm issue. It creates a new TCP option which includes a key identifier and has a new MAC algorithm (the mandatory to implement is AES-128-CMAC-96). The key management system is a fairly complicated list of static keys with overlapping usable time windows. The new option also includes optional protection for TCP options (RFC 2385 had none) and a few other minder features. My detailed comments can be found on my post about this to SAAG [Re06]. For the purposes of the discussion here, my major comment is that I think time-based windows and large keyrings are a bad idea and not needed. Key-Ids are quite sufficient. draft-touch-tcpm-tcp-simple-auth-01 ----------------------------------- This draft is a replacement for RFC 2385 which allows pluggable MAC algorithms, integrity for the TCP options, and some support for rekeying (see below). It also provides for more explicit detail about the interface of the option with TCP. Otherwise, it is very similar to RFC 2385. I have two major comments about this draft: 1. Although the MAC algorithms are pluggable, the default is HMAC-MD5-96. Given the current status of MD5, I don't believe that the IETF should be standardizing any MD5-based algorithms. 2. I'm not convinced that the rekeying strategy described here is OK. Note that TCP-SA's support for rekeying is designed to be minimal. As with the IPsec suite, segments carry only enough context to identify the security association [RFC4301][RFC4306]. In TCP-SA, this context is provided by the socket pair (IP addresses and ports for source and destination). The key is identified only in the LSAD, and coordinated by a separate mechanism not specified in TCP-SA. This differs from recent approaches that assume an additional key ID field and require support for multiple concurrently active keys on a single association [Be06][Bo06][We05][We06]. Such complexity is not necessary in TCP-SA because TCP is already robust to segment loss. ISTM that this only works properly if the key changes are more or less synchronized. Consider what happens in the following sequence of events: 0s A and B are using K1 10s A changes to K2 60s A sends data packet 600s A gives up and aborts the connection (assume a total timeout of 9 minutes) 601s B changes to K2 So, the maximum time difference between A and B rekeying has to be less than the total timeout. This is plausible with automatic rekeying, but in cases where it's manual seems difficult. What happens when A calls B and says "rekey now" but then B decides to go get a cup of coffee before rekeying? Obviously, it can be made to work, but it seems undesirable. In order to allow longer gaps between rekeying on the two sides, you need to support multiple parallel keys. SUMMARY OF PROPOSALS -------------------- Be06 BWLVW06 TA06 -------------------------------- Key Identifiers No Yes No Trial Authentication Yes No No New MAC No Yes Yes [Be06] S. Bellovin, "Key Change Strategies for TCP-MD5", draft-bellovin-keyroll2385-00.txt, June 2006. [BWVLW06] R. Bonica, B. Weis, S. Viswanathan, A. Lange, O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", draft-bonica-tcp-auth-04, February, 2006. [Re06] E. Rescorla, Message to SAAG Mailing List http://mailman.mit.edu/pipermail/saag/2006q2/001583.html [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [TA06] J. Touch, A. Mankin, "The TCP Simple Authentication Option", draft-touch-tcpm-tcp-simple-auth-01.txt, June 2006. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 10 12:34:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyiH-0005GL-Gm; Mon, 10 Jul 2006 12:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyiF-0005GF-NJ for tcpm@ietf.org; Mon, 10 Jul 2006 12:34:23 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzyiD-0002jM-7d for tcpm@ietf.org; Mon, 10 Jul 2006 12:34:23 -0400 Received: from [132.219.10.198] (h0ac6-net84db.lab.risq.net [132.219.10.198] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6AGXFH12821; Mon, 10 Jul 2006 09:33:15 -0700 (PDT) Message-ID: <44B28144.9010409@isi.edu> Date: Mon, 10 Jul 2006 09:33:08 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: EKR Subject: Re: [tcpm] [Repost] Review of the various TCP MACing proposals References: <20060710161048.1259C1CC22@delta.rtfm.com> In-Reply-To: <20060710161048.1259C1CC22@delta.rtfm.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467192367==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0467192367== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC1F4C255171253284E9C5D4E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC1F4C255171253284E9C5D4E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable EKR wrote: > I originally sent this to bts, but it should probably be > posted here.... >=20 > -Ekr >=20 > BACKGROUND > ---------- > There's growing discomfort about the security of TCP MD5 > [RFC 2385]. This discomfort comes from a variety of factors: >=20 > 1. TCP MD5 is an old-style H(Data || Key) design rather > than a more modern HMAC-style construction. > 2. Recent work by Wang et al. has cast doubt on the > security of MD5 in general and it may be applicable > to this construction. > 3. TCP MD5 doesn't support key rollover, which means > that rekeying requires tearing down existing connections > which is a problem for BGP. >=20 > There has been a lot of discussion about what to do to=20 > correct these failings. One obvious strategy (though by > far not the only one) is to produce an improved version > of RFC 2385. This memo discusses three such proposals. >=20 > draft-bellovin-keyroll2385-00 [Be06] > draft-bonica-tcp-auth-04 [BWVLW06] > draft-touch-tcpm-tcp-simple-auth-01 [TA06] >=20 > Note that there are other architectural options, such as > running everything over IPsec that are not discussed here. > The intent is to discuss merely the proposals which have > a lot of commonality. >=20 >=20 > COMMON ISSUES > ------------- > A number of common issues come up here: >=20 > - Use of key identifiers: One natural way to support key rollover > is to incorporate a key (or association) identifier. This=20 > allows the receiving party to determine which key was used > to protect the received segment. It also provides a potential > hook for external key management, e.g., via IKE. Where is that key ID in IPsec AH? There's only an SPI, the SPI indexes a database with the key ID, which can change via a separate (IKE) protocol. In TCP-SA (simple-auth), we use the same principle: where SPI -> socket pair (IP pair, port pair) > - Trial Authentication: If multiple parallel keys are used for > rollover and a key identifier is not used, then the receiver > potentially needs to try all the available keys. Concerns > have been raised about the potential for computation-based > DoS in such systems. How is this handled in IPsec/IKE? > - Replacement of MAC algorithm: One way to address issues > (1) and (2) above is to replace the current construction > with a more modern one such as HMAC. There are actually > two issues here, the construction and the underlying > digest. =2E.. > draft-touch-tcpm-tcp-simple-auth-01 > ----------------------------------- > This draft is a replacement for RFC 2385 which allows pluggable > MAC algorithms, integrity for the TCP options, and some support > for rekeying (see below). It also provides for more explicit > detail about the interface of the option with TCP. > Otherwise, it is very similar to RFC 2385. >=20 > I have two major comments about this draft: >=20 > 1. Although the MAC algorithms are pluggable, the default is > HMAC-MD5-96. Given the current status of MD5, I don't=20 > believe that the IETF should be standardizing any MD5-based > algorithms.=20 The issues with MD5 are constrained to non-HMAC uses. The security community, AFAICT still suggests HMAC-MD5. HMAC-MD5 is much faster than HMAC-SHA1 > 2. I'm not convinced that the rekeying strategy described > here is OK. >=20 > Note that TCP-SA's support for rekeying is designed to be minimal. A= s=20 > with the IPsec suite, segments carry only enough context to identify= =20 > the security association [RFC4301][RFC4306]. In TCP-SA, this context= =20 > is provided by the socket pair (IP addresses and ports for source an= d=20 > destination). The key is identified only in the LSAD, and coordinate= d=20 > by a separate mechanism not specified in TCP-SA. This differs from=20 > recent approaches that assume an additional key ID field and require= =20 > support for multiple concurrently active keys on a single associatio= n=20 > [Be06][Bo06][We05][We06]. Such complexity is not necessary in TCP-SA= =20 > because TCP is already robust to segment loss.=20 >=20 > ISTM that this only works properly if the key changes are more > or less synchronized. Consider what happens in the following > sequence of events: >=20 > 0s A and B are using K1 > 10s A changes to K2 > 60s A sends data packet > > 600s A gives up and aborts the connection (assume a total timeout > of 9 minutes) > 601s B changes to K2 We do assume rough synchronization, and note that there will be packet loss during the rollover. A key resynch that spans 9 minutes will break lots of things. > So, the maximum time difference between A and B rekeying has to > be less than the total timeout. This is plausible with automatic > rekeying, but in cases where it's manual seems difficult. What > happens when A calls B and says "rekey now" but then B decides > to go get a cup of coffee before rekeying? Obviously, it can=20 > be made to work, but it seems undesirable.=20 That depends on the implementation of the LSAD updates; one can design the implementation to make new keys active at a scheduled time in the future. That means that the clocktime on each system then becomes a security issue, though. > In order to allow longer gaps between rekeying on the two sides, > you need to support multiple parallel keys. >=20 > SUMMARY OF PROPOSALS > -------------------- > Be06 BWLVW06 TA06 > -------------------------------- > Key Identifiers No Yes No > Trial Authentication Yes No No > New MAC No Yes Yes This summary doesn't address the need for integrated key management, the effect on TCP's timers and window mechanisms, and the impact on TCP's state diagrams. IMO, those are as - if not more - important consideration= s. Joe --------------enigC1F4C255171253284E9C5D4E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsoFEE5f5cImnZrsRAhGKAKDVJVtnM/qv5gHh2xfNd3ymXDVnYwCfYIsW S3FXBRfVzAQe4NavzUfpU7w= =GgMl -----END PGP SIGNATURE----- --------------enigC1F4C255171253284E9C5D4E-- --===============0467192367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0467192367==-- From tcpm-bounces@ietf.org Mon Jul 10 13:48:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzsL-0001TZ-2w; Mon, 10 Jul 2006 13:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzsJ-0001TU-7R for tcpm@ietf.org; Mon, 10 Jul 2006 13:48:51 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzsI-0008Hq-Lf; Mon, 10 Jul 2006 13:48:51 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6AHm4H02789; Mon, 10 Jul 2006 10:48:04 -0700 (PDT) Message-ID: <44B292CE.9040509@isi.edu> Date: Mon, 10 Jul 2006 10:47:58 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: EKR Subject: Re: [tcpm] [Repost] Review of the various TCP MACing proposals References: <20060710161048.1259C1CC22@delta.rtfm.com> In-Reply-To: <20060710161048.1259C1CC22@delta.rtfm.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: tcpm@ietf.org, bts@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1781886469==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1781886469== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig52242D44555049553F860F0A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52242D44555049553F860F0A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable EKR wrote: > I originally sent this to bts, but it should probably be > posted here.... In case the TCPM folk want to track this, the BTS mailing list is: https://rtg.ietf.org/mailman/listinfo/bts That list appears to have been created specifically for this discussion, so it might be useful to shift the discussion there. Joe >=20 > -Ekr >=20 > BACKGROUND > ---------- > There's growing discomfort about the security of TCP MD5 > [RFC 2385]. This discomfort comes from a variety of factors: >=20 > 1. TCP MD5 is an old-style H(Data || Key) design rather > than a more modern HMAC-style construction. > 2. Recent work by Wang et al. has cast doubt on the > security of MD5 in general and it may be applicable > to this construction. > 3. TCP MD5 doesn't support key rollover, which means > that rekeying requires tearing down existing connections > which is a problem for BGP. >=20 > There has been a lot of discussion about what to do to=20 > correct these failings. One obvious strategy (though by > far not the only one) is to produce an improved version > of RFC 2385. This memo discusses three such proposals. >=20 > draft-bellovin-keyroll2385-00 [Be06] > draft-bonica-tcp-auth-04 [BWVLW06] > draft-touch-tcpm-tcp-simple-auth-01 [TA06] >=20 > Note that there are other architectural options, such as > running everything over IPsec that are not discussed here. > The intent is to discuss merely the proposals which have > a lot of commonality. >=20 >=20 > COMMON ISSUES > ------------- > A number of common issues come up here: >=20 > - Use of key identifiers: One natural way to support key rollover > is to incorporate a key (or association) identifier. This=20 > allows the receiving party to determine which key was used > to protect the received segment. It also provides a potential > hook for external key management, e.g., via IKE. >=20 > - Trial Authentication: If multiple parallel keys are used for > rollover and a key identifier is not used, then the receiver > potentially needs to try all the available keys. Concerns > have been raised about the potential for computation-based > DoS in such systems. > =20 > - Replacement of MAC algorithm: One way to address issues > (1) and (2) above is to replace the current construction > with a more modern one such as HMAC. There are actually > two issues here, the construction and the underlying > digest. >=20 >=20 > draft-bellovin-keyroll2385-00 > ----------------------------- > This draft is only intended to address the key rollover problem. It is > bits on the wire compatible with RFC 2385 and simply provides > algorithms on the receiver and sender side for use and detection of > new keys. No key identifier, so there is a potential for DoS as > indicated above. The MAC algorithm is not replaced. >=20 > Not replacing the MAC algorithm makes me fairly uncomfortable. The > construction in RFC 2385 is almost certainly weak and is getting > weaker as time goes on. If we're going to go to the trouble of doing > anything I believe that we should replace the MAC algorithm with a > more modern one. >=20 > I'm also not sure I think that the receiver-side algorithm proposed > here is the best choice, since it seems designed to allow the use of > multiple keys more or less indefinitely (until the old one is expired) > rather than having a clean cutover after which the old key is no > longer accepted. ISTM that you could use TCP sequence numbers to > determine a low-water mark after which the old key could no longer be > used. >=20 >=20 > draft-bonica-tcp-auth-04 > ------------------------ > This draft addresses both the key rollover issue and the MAC > algorithm issue. It creates a new TCP option which includes a key > identifier and has a new MAC algorithm (the mandatory to implement is > AES-128-CMAC-96). The key management system is a fairly complicated > list of static keys with overlapping usable time windows. The new > option also includes optional protection for TCP options (RFC 2385 had > none) and a few other minder features. >=20 > My detailed comments can be found on my post about this to SAAG > [Re06]. For the purposes of the discussion here, my major comment > is that I think time-based windows and large keyrings are a bad=20 > idea and not needed. Key-Ids are quite sufficient. >=20 >=20 > draft-touch-tcpm-tcp-simple-auth-01 > ----------------------------------- > This draft is a replacement for RFC 2385 which allows pluggable > MAC algorithms, integrity for the TCP options, and some support > for rekeying (see below). It also provides for more explicit > detail about the interface of the option with TCP. > Otherwise, it is very similar to RFC 2385. >=20 > I have two major comments about this draft: >=20 > 1. Although the MAC algorithms are pluggable, the default is > HMAC-MD5-96. Given the current status of MD5, I don't=20 > believe that the IETF should be standardizing any MD5-based > algorithms.=20 >=20 > 2. I'm not convinced that the rekeying strategy described > here is OK. >=20 > Note that TCP-SA's support for rekeying is designed to be minimal. A= s=20 > with the IPsec suite, segments carry only enough context to identify= =20 > the security association [RFC4301][RFC4306]. In TCP-SA, this context= =20 > is provided by the socket pair (IP addresses and ports for source an= d=20 > destination). The key is identified only in the LSAD, and coordinate= d=20 > by a separate mechanism not specified in TCP-SA. This differs from=20 > recent approaches that assume an additional key ID field and require= =20 > support for multiple concurrently active keys on a single associatio= n=20 > [Be06][Bo06][We05][We06]. Such complexity is not necessary in TCP-SA= =20 > because TCP is already robust to segment loss.=20 >=20 > ISTM that this only works properly if the key changes are more > or less synchronized. Consider what happens in the following > sequence of events: >=20 > 0s A and B are using K1 > 10s A changes to K2 > 60s A sends data packet > > 600s A gives up and aborts the connection (assume a total timeout > of 9 minutes) > 601s B changes to K2 >=20 > So, the maximum time difference between A and B rekeying has to > be less than the total timeout. This is plausible with automatic > rekeying, but in cases where it's manual seems difficult. What > happens when A calls B and says "rekey now" but then B decides > to go get a cup of coffee before rekeying? Obviously, it can=20 > be made to work, but it seems undesirable.=20 >=20 > In order to allow longer gaps between rekeying on the two sides, > you need to support multiple parallel keys. >=20 >=20 >=20 > SUMMARY OF PROPOSALS > -------------------- > Be06 BWLVW06 TA06 > -------------------------------- > Key Identifiers No Yes No > Trial Authentication Yes No No > New MAC No Yes Yes >=20 >=20 >=20 >=20 > [Be06] S. Bellovin, "Key Change Strategies for TCP-MD5", > draft-bellovin-keyroll2385-00.txt, June 2006. >=20 > [BWVLW06] R. Bonica, B. Weis, S. Viswanathan, A. Lange,=20 > O. Wheeler, "Authentication for TCP-based Routing > and Management Protocols", draft-bonica-tcp-auth-04, > February, 2006. =20 >=20 > [Re06] E. Rescorla, Message to SAAG Mailing List > http://mailman.mit.edu/pipermail/saag/2006q2/001583.html >=20 > [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC 2385, August 1998. >=20 > [TA06] J. Touch, A. Mankin, "The TCP Simple Authentication Option", > draft-touch-tcpm-tcp-simple-auth-01.txt, June 2006. >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig52242D44555049553F860F0A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEspLOE5f5cImnZrsRAv0QAKC4L+5wEZPlw9pVoln8K3YC34wRlACgieTt m8PLWuhR+gpYZlLQz9hxkSs= =Lj4F -----END PGP SIGNATURE----- --------------enig52242D44555049553F860F0A-- --===============1781886469== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1781886469==-- From tcpm-bounces@ietf.org Mon Jul 10 13:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzvW-0001nE-Av; Mon, 10 Jul 2006 13:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzvV-0001lD-BH for tcpm@ietf.org; Mon, 10 Jul 2006 13:52:09 -0400 Received: from [132.219.15.238] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzvT-0000Es-P3 for tcpm@ietf.org; Mon, 10 Jul 2006 13:52:09 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 392E01CC22; Mon, 10 Jul 2006 10:51:14 -0700 (PDT) To: Joe Touch Subject: Re: [tcpm] [Repost] Review of the various TCP MACing proposals In-reply-to: Your message of "Mon, 10 Jul 2006 09:33:08 PDT." <44B28144.9010409@isi.edu> X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 10 Jul 2006 10:51:14 -0700 From: EKR Message-Id: <20060710175114.392E01CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: bts@rtg.ietf.org, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > > ------------- > > A number of common issues come up here: > > > > - Use of key identifiers: One natural way to support key rollover > > is to incorporate a key (or association) identifier. This > > allows the receiving party to determine which key was used > > to protect the received segment. It also provides a potential > > hook for external key management, e.g., via IKE. > > Where is that key ID in IPsec AH? > > There's only an SPI, the SPI indexes a database with the key ID, which > can change via a separate (IKE) protocol. > > In TCP-SA (simple-auth), we use the same principle: > where SPI -> socket pair (IP pair, port pair) In IKE as I understand it, each time you rekey you generate a new, unique SPI, so SPIs uniquely identify keys. As I understand your design, IP pair, port pair doesn't uniquely specify the keys, so I think these are different cases. > > - Trial Authentication: If multiple parallel keys are used for > > rollover and a key identifier is not used, then the receiver > > potentially needs to try all the available keys. Concerns > > have been raised about the potential for computation-based > > DoS in such systems. > > How is this handled in IPsec/IKE? How is what handled in IPsec/IKE? IKE doesn't have, or need, a trial authentication technique, AFAIK, because the SPI is sufficient to determine the key. > > 1. Although the MAC algorithms are pluggable, the default is > > HMAC-MD5-96. Given the current status of MD5, I don't > > believe that the IETF should be standardizing any MD5-based > > algorithms. > > The issues with MD5 are constrained to non-HMAC uses. The security > community, AFAICT still suggests HMAC-MD5. Not that I know of, no. Rather, the guidance is that there's no HMAC-MD5 emergency, but we shouldn't be stuffing it in new things. > HMAC-MD5 is much faster than > HMAC-SHA1 Yes. > > 0s A and B are using K1 > > 10s A changes to K2 > > 60s A sends data packet > > > > 600s A gives up and aborts the connection (assume a total timeout > > of 9 minutes) > > 601s B changes to K2 > > We do assume rough synchronization, and note that there will be packet > loss during the rollover. A key resynch that spans 9 minutes will break > lots of things. Well, it will break lots of things unless you design your protocol so it doesn't. It's straightforward to design manual key management systems that work with very long (hours to days) time lags. > > So, the maximum time difference between A and B rekeying has to > > be less than the total timeout. This is plausible with automatic > > rekeying, but in cases where it's manual seems difficult. What > > happens when A calls B and says "rekey now" but then B decides > > to go get a cup of coffee before rekeying? Obviously, it can > > be made to work, but it seems undesirable. > > That depends on the implementation of the LSAD updates; one can design > the implementation to make new keys active at a scheduled time in the > future. That means that the clocktime on each system then becomes a > security issue, though. Right. Which is a disadvantage of this design. > This summary doesn't address the need for integrated key management, the > effect on TCP's timers and window mechanisms, and the impact on TCP's > state diagrams. IMO, those are as - if not more - important considerations. I'd love to see you update a table to include these issues... -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 10 14:22:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00OT-0000iD-OL; Mon, 10 Jul 2006 14:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00OR-0000h8-9T for tcpm@ietf.org; Mon, 10 Jul 2006 14:22:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00OP-0004lw-Jt for tcpm@ietf.org; Mon, 10 Jul 2006 14:22:03 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2006 11:22:02 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="304550809:sNHT35543080" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k6AIM1nI005881; Mon, 10 Jul 2006 11:22:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6AILvft017588; Mon, 10 Jul 2006 11:21:58 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:21:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] [Repost] Review of the various TCP MACing proposals Date: Mon, 10 Jul 2006 11:21:57 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801D29A3A@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] [Repost] Review of the various TCP MACing proposals Thread-Index: AcakO5A/IIS3tfnLQeilBIqkiDyJdgADwW+A From: "Anantha Ramaiah \(ananth\)" To: "EKR" , X-OriginalArrivalTime: 10 Jul 2006 18:21:57.0982 (UTC) FILETIME=[BAC927E0:01C6A44D] DKIM-Signature: a=rsa-sha1; q=dns; l=8033; t=1152555721; x=1153419721; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20[Repost]=20Review=20of=20the=20various=20TCP=20MACing=2 0proposals; X=v=3Dcisco.com=3B=20h=3D348QjpvMfA9Hsik82eTOtUzsr9Q=3D; b=dzfG/G4wwuPYsZfIObbIC/wRys4g2ptBBTJzw3Cxe69LmlUParWyWDYdDwnHiysx7/qtBEK5 msbwMFP5W6plAfRqKhRh5elzpkhbURgLbasQul1NfYkB3I+lcFp0ShGr; Authentication-Results: sj-dkim-6.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Eric, Just a quick observation below.. > 3. TCP MD5 doesn't support key rollover, which means > that rekeying requires tearing down existing connections > which is a problem for BGP. Since the TCP MD5 RFC (2385) does not specify about the key change and the associated actions, implementations tried to do what they liked. There is no implication that the session needs to go down if the key is changed.=20 It was true that at one point of time when the password (key changed) the session would be closed and re-opened again by BGP. This has been corrected by all major BGP implementations. (LDP and MSDP as well, although I haven't checked) -Anantha >=20 > There has been a lot of discussion about what to do to=20 > correct these failings. One obvious strategy (though by far=20 > not the only one) is to produce an improved version of RFC=20 > 2385. This memo discusses three such proposals. >=20 > draft-bellovin-keyroll2385-00 [Be06] > draft-bonica-tcp-auth-04 [BWVLW06] > draft-touch-tcpm-tcp-simple-auth-01 [TA06] >=20 > Note that there are other architectural options, such as=20 > running everything over IPsec that are not discussed here. > The intent is to discuss merely the proposals which have a=20 > lot of commonality. >=20 >=20 > COMMON ISSUES > ------------- > A number of common issues come up here: >=20 > - Use of key identifiers: One natural way to support key rollover > is to incorporate a key (or association) identifier. This > allows the receiving party to determine which key was used > to protect the received segment. It also provides a potential > hook for external key management, e.g., via IKE. >=20 > - Trial Authentication: If multiple parallel keys are used for > rollover and a key identifier is not used, then the receiver > potentially needs to try all the available keys. Concerns > have been raised about the potential for computation-based > DoS in such systems. > =20 > - Replacement of MAC algorithm: One way to address issues > (1) and (2) above is to replace the current construction > with a more modern one such as HMAC. There are actually > two issues here, the construction and the underlying > digest. >=20 >=20 > draft-bellovin-keyroll2385-00 > ----------------------------- > This draft is only intended to address the key rollover=20 > problem. It is bits on the wire compatible with RFC 2385 and=20 > simply provides algorithms on the receiver and sender side=20 > for use and detection of new keys. No key identifier, so=20 > there is a potential for DoS as indicated above. The MAC=20 > algorithm is not replaced. >=20 > Not replacing the MAC algorithm makes me fairly=20 > uncomfortable. The construction in RFC 2385 is almost=20 > certainly weak and is getting weaker as time goes on. If=20 > we're going to go to the trouble of doing anything I believe=20 > that we should replace the MAC algorithm with a more modern one. >=20 > I'm also not sure I think that the receiver-side algorithm=20 > proposed here is the best choice, since it seems designed to=20 > allow the use of multiple keys more or less indefinitely=20 > (until the old one is expired) rather than having a clean=20 > cutover after which the old key is no longer accepted. ISTM=20 > that you could use TCP sequence numbers to determine a=20 > low-water mark after which the old key could no longer be used. >=20 >=20 > draft-bonica-tcp-auth-04 > ------------------------ > This draft addresses both the key rollover issue and the MAC=20 > algorithm issue. It creates a new TCP option which includes a=20 > key identifier and has a new MAC algorithm (the mandatory to=20 > implement is AES-128-CMAC-96). The key management system is a=20 > fairly complicated list of static keys with overlapping=20 > usable time windows. The new option also includes optional=20 > protection for TCP options (RFC 2385 had > none) and a few other minder features. >=20 > My detailed comments can be found on my post about this to=20 > SAAG [Re06]. For the purposes of the discussion here, my=20 > major comment is that I think time-based windows and large=20 > keyrings are a bad idea and not needed. Key-Ids are quite sufficient. >=20 >=20 > draft-touch-tcpm-tcp-simple-auth-01 > ----------------------------------- > This draft is a replacement for RFC 2385 which allows pluggable > MAC algorithms, integrity for the TCP options, and some support > for rekeying (see below). It also provides for more explicit > detail about the interface of the option with TCP. > Otherwise, it is very similar to RFC 2385. >=20 > I have two major comments about this draft: >=20 > 1. Although the MAC algorithms are pluggable, the default is > HMAC-MD5-96. Given the current status of MD5, I don't=20 > believe that the IETF should be standardizing any MD5-based > algorithms.=20 >=20 > 2. I'm not convinced that the rekeying strategy described > here is OK. >=20 > Note that TCP-SA's support for rekeying is designed to be=20 > minimal. As=20 > with the IPsec suite, segments carry only enough context=20 > to identify=20 > the security association [RFC4301][RFC4306]. In TCP-SA,=20 > this context=20 > is provided by the socket pair (IP addresses and ports for=20 > source and=20 > destination). The key is identified only in the LSAD, and=20 > coordinated=20 > by a separate mechanism not specified in TCP-SA. This differs from=20 > recent approaches that assume an additional key ID field=20 > and require=20 > support for multiple concurrently active keys on a single=20 > association=20 > [Be06][Bo06][We05][We06]. Such complexity is not necessary=20 > in TCP-SA=20 > because TCP is already robust to segment loss.=20 >=20 > ISTM that this only works properly if the key changes are more > or less synchronized. Consider what happens in the following > sequence of events: >=20 > 0s A and B are using K1 > 10s A changes to K2 > 60s A sends data packet > > 600s A gives up and aborts the connection (assume a total timeout > of 9 minutes) > 601s B changes to K2 >=20 > So, the maximum time difference between A and B rekeying has to > be less than the total timeout. This is plausible with automatic > rekeying, but in cases where it's manual seems difficult. What > happens when A calls B and says "rekey now" but then B decides > to go get a cup of coffee before rekeying? Obviously, it can=20 > be made to work, but it seems undesirable.=20 >=20 > In order to allow longer gaps between rekeying on the two sides, > you need to support multiple parallel keys. >=20 >=20 >=20 > SUMMARY OF PROPOSALS > -------------------- > Be06 BWLVW06 TA06 > -------------------------------- > Key Identifiers No Yes No > Trial Authentication Yes No No > New MAC No Yes Yes >=20 >=20 >=20 >=20 > [Be06] S. Bellovin, "Key Change Strategies for TCP-MD5", > draft-bellovin-keyroll2385-00.txt, June 2006. >=20 > [BWVLW06] R. Bonica, B. Weis, S. Viswanathan, A. Lange,=20 > O. Wheeler, "Authentication for TCP-based Routing > and Management Protocols", draft-bonica-tcp-auth-04, > February, 2006. =20 >=20 > [Re06] E. Rescorla, Message to SAAG Mailing List > http://mailman.mit.edu/pipermail/saag/2006q2/001583.html >=20 > [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC 2385, August 1998. >=20 > [TA06] J. Touch, A. Mankin, "The TCP Simple Authentication Option", > draft-touch-tcpm-tcp-simple-auth-01.txt, June 2006. >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 10 16:54:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02lw-0001l6-WC; Mon, 10 Jul 2006 16:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02lv-0001gr-EN for tcpm@ietf.org; Mon, 10 Jul 2006 16:54:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02lu-00079V-5F for tcpm@ietf.org; Mon, 10 Jul 2006 16:54:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2006 13:54:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k6AKsPKx009555; Mon, 10 Jul 2006 13:54:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6AKsGDp023323; Mon, 10 Jul 2006 13:54:25 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 13:54:24 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 13:54:23 -0700 Message-ID: <44B2BE80.6030609@cisco.com> Date: Mon, 10 Jul 2006 16:54:24 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro, Jr." Subject: Re: [tcpm] TCPx2 References: <20060508172852.GB26444@grc.nasa.gov> <70C6EFCDFC8AAD418EF7063CD132D06493C528@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <6.2.1.2.2.20060508141240.0316bfd8@antipi> <445F8DA8.10609@bbn.com> In-Reply-To: <445F8DA8.10609@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 20:54:23.0639 (UTC) FILETIME=[0605AA70:01C6A463] DKIM-Signature: a=rsa-sha1; q=dns; l=395; t=1152564865; x=1153428865; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20TCPx2; X=v=3Dcisco.com=3B=20h=3D6YdO/dJhE78vuZrkIfasb/eiXsA=3D; b=ZQmM410MTZazIjmVUJy9EfCaOTNDegpWSrUi/YHQFWhOlciJT879xeAdIiB1ZLxSuWIs00F+ GT6lTs6YYzb5qb3LjG2rSIni7HIzuFporzAvsLXolAB350N7fOG9jaRd; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Armando L. Caro, Jr. wrote: > Ah, but now we are going down the path of an entirely different > protocol. Mark's intention was to keep the protocol semantics the same, > but just get more header space. > And from Christians "want" list.. it looks a lot like SCTP.. with a few exceptions :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 10 17:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02rP-0004KF-R0; Mon, 10 Jul 2006 17:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02rO-0004K7-HO for tcpm@ietf.org; Mon, 10 Jul 2006 17:00:06 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02rN-0007L5-6q for tcpm@ietf.org; Mon, 10 Jul 2006 17:00:06 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6AKxjr3093065; Mon, 10 Jul 2006 13:59:45 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id C7C0C77A9D4; Mon, 10 Jul 2006 16:59:43 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CD0C2435116; Mon, 10 Jul 2006 16:58:34 -0400 (EDT) To: Randall Stewart From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <44B2BE80.6030609@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Going to California MIME-Version: 1.0 Date: Mon, 10 Jul 2006 16:58:34 -0400 Message-Id: <20060710205834.CD0C2435116@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635001125==" Errors-To: tcpm-bounces@ietf.org --===============0635001125== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline BTW, in case folks had not noticed, I am going to do a few minutes on TCPx2 (and, more generally "TCP Futures") at the TSV area meeting Thu morning this week. I am packing my backpack with rotten vegetables and will retaliate. :-) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEsr96WyrrWs4yIs4RAi+PAJ9Bu26YJjAfEY/fXUivj/+Mx6ezXwCfQTOB hffP2ZJ1n5MTybh8beCXsU8= =EM7w -----END PGP SIGNATURE----- --=_bOundary-- --===============0635001125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0635001125==-- From tcpm-bounces@ietf.org Mon Jul 10 17:11:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G031y-0005bH-V2; Mon, 10 Jul 2006 17:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G031y-0005bC-F0 for tcpm@ietf.org; Mon, 10 Jul 2006 17:11:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G031x-0007nu-4b for tcpm@ietf.org; Mon, 10 Jul 2006 17:11:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2006 14:11:01 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="328171722:sNHT31368644" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k6ALB0fO009817; Mon, 10 Jul 2006 14:11:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6ALAvTQ025927; Mon, 10 Jul 2006 14:10:57 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 14:10:57 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 14:10:56 -0700 Message-ID: <44B2C261.6000503@cisco.com> Date: Mon, 10 Jul 2006 17:10:57 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060510141145.9DB9577AC74@guns.icir.org> In-Reply-To: <20060510141145.9DB9577AC74@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 21:10:56.0529 (UTC) FILETIME=[55D4A810:01C6A465] DKIM-Signature: a=rsa-sha1; q=dns; l=1348; t=1152565860; x=1153429860; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20middleboxes=20and=20Re=3A=20[tcpm]=20TCPx2; X=v=3Dcisco.com=3B=20h=3Dj4Hk+WxNpUCoRVt9L75V2yiitl4=3D; b=qwCH6lhSaAVujJNdC1yU/Rf5XiQElMk54HdpMEazzYDJSXEVlJVcp0WObRNoU6wB6N5i2RYA MNkmnEFqKWWOHOrGzHbefhQ30ObyqgJxR3fsssGfoGwLigxZQ8mElD3Y; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >>I think that the most likely failure mode would be >>that the routes change, the packets go through a new AS, and >>that new AS has different policies as to what they do and >>do not let into/through their network. This is most likely >>not a problem with TCPx1 -- ISPs, etc, do not usually >>filter transit/etc traffic based on TCP port numbers or >>the like -- but they might/do filter based on IP protocol >>number... (hence, my "stick it in UDP" comment). > > > I guess my mental model is that transit traffic is not filtered like > this. So, my intuition is that this is all theoretical. But, I have no > data. I wonder if any of the SCTP or DCCP folk have experience with > running tests across the Internet that were impacted by filtering that > was not near the edge. > I have never been filtered with SCTP across the net.. but forget getting through NAT's and FW's.. there are a FEW that do SCTP.. but not many.. I am still working on that :-D R > allman > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 10 18:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04Hl-0002nn-Js; Mon, 10 Jul 2006 18:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04Hk-0002ni-9u for tcpm@ietf.org; Mon, 10 Jul 2006 18:31:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G04Hj-0005TV-0D for tcpm@ietf.org; Mon, 10 Jul 2006 18:31:24 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2006 15:31:22 -0700 X-IronPort-AV: i="4.06,226,1149490800"; d="scan'208"; a="304650461:sNHT30293696" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k6AMVMCj021181; Mon, 10 Jul 2006 15:31:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6AMVMfr015406; Mon, 10 Jul 2006 15:31:22 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 15:31:22 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 15:31:21 -0700 Message-ID: <44B2D53A.8030608@cisco.com> Date: Mon, 10 Jul 2006 18:31:22 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] TCPx2 References: <20060710205834.CD0C2435116@lawyers.icir.org> In-Reply-To: <20060710205834.CD0C2435116@lawyers.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 22:31:21.0740 (UTC) FILETIME=[91E16CC0:01C6A470] DKIM-Signature: a=rsa-sha1; q=dns; l=461; t=1152570682; x=1153434682; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20TCPx2; X=v=3Dcisco.com=3B=20h=3D6YdO/dJhE78vuZrkIfasb/eiXsA=3D; b=AInVv10JXkcuuoeJaew+uUJ+CLn0NQEXqDzartmXHQuWmNQjxu6+j8zQzKb3r8dEugkjeIAO SPFaLqcQ4ifq+7WBIL0aUrEhvmfFEvpQuxgGJje2sQ6HQYhL3wTQMPU4; Authentication-Results: sj-dkim-6.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > BTW, in case folks had not noticed, I am going to do a few minutes on > TCPx2 (and, more generally "TCP Futures") at the TSV area meeting Thu > morning this week. I am packing my backpack with rotten vegetables and > will retaliate. :-) > > allman > > > Hmm.. did you bring a garbage can lid so you can improvise a shield? :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 10 18:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04TX-0001Ag-Hs; Mon, 10 Jul 2006 18:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04TV-0001AQ-Uh for tcpm@ietf.org; Mon, 10 Jul 2006 18:43:33 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G04TU-0006LZ-CL for tcpm@ietf.org; Mon, 10 Jul 2006 18:43:33 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6AMhVaE095610; Mon, 10 Jul 2006 15:43:31 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 58EDC77A9D4; Mon, 10 Jul 2006 18:43:29 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 46DC84352B7; Mon, 10 Jul 2006 18:42:20 -0400 (EDT) To: Randall Stewart From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <44B2D53A.8030608@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Going to California MIME-Version: 1.0 Date: Mon, 10 Jul 2006 18:42:20 -0400 Message-Id: <20060710224220.46DC84352B7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0327654211==" Errors-To: tcpm-bounces@ietf.org --===============0327654211== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Hmm.. did you bring a garbage can lid so you can > improvise a shield? :-D Nope. Wouldn't fit in my bag. I'll just use Falk ... allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEstfMWyrrWs4yIs4RAqxNAJ9BRl3H6qygfX0TzG4Q63i2ZDO/QwCfYWVj bnvHACn0JHAOrOit2eSbNbo= =lv0o -----END PGP SIGNATURE----- --=_bOundary-- --===============0327654211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0327654211==-- From tcpm-bounces@ietf.org Tue Jul 11 10:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JDZ-0003Ep-K1; Tue, 11 Jul 2006 10:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JDY-0003Ee-9G for tcpm@ietf.org; Tue, 11 Jul 2006 10:28:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0FsW-00037H-3x for tcpm@ietf.org; Tue, 11 Jul 2006 06:54:08 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0FRb-00027u-QC for tcpm@ietf.org; Tue, 11 Jul 2006 06:26:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2006 03:26:20 -0700 X-IronPort-AV: i="4.06,227,1149490800"; d="scan'208"; a="328267804:sNHT30896992" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k6BAQJLm021758; Tue, 11 Jul 2006 03:26:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6BAPYTg023382; Tue, 11 Jul 2006 03:26:18 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 03:26:08 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 03:26:07 -0700 Message-ID: <44B37CBB.9080802@cisco.com> Date: Tue, 11 Jul 2006 06:26:03 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] TCPx2 References: <20060710224220.46DC84352B7@lawyers.icir.org> In-Reply-To: <20060710224220.46DC84352B7@lawyers.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 10:26:08.0067 (UTC) FILETIME=[6C1F9930:01C6A4D4] DKIM-Signature: a=rsa-sha1; q=dns; l=326; t=1152613579; x=1153477579; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20TCPx2; X=v=3Dcisco.com=3B=20h=3D6YdO/dJhE78vuZrkIfasb/eiXsA=3D; b=ilC7CuSUjVmdpzQZqq5Vvo2ngkdNRU4gAbVHpSPm+3B9hAMWe3RyzygyDmHP564+L4cd7ZGD txnzAMpc9+0+uhDJiBeijw/cZLa89gW1qAjXa2AoBGSerdKNrAJM6lm0; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.5 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >>Hmm.. did you bring a garbage can lid so you can >>improvise a shield? :-D > > > Nope. Wouldn't fit in my bag. I'll just use Falk ... > > allman > > > I am fine with that (sorry Aaron) :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 11 14:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NJn-0006xM-Ka; Tue, 11 Jul 2006 14:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NJm-0006xH-3z for tcpm@ietf.org; Tue, 11 Jul 2006 14:50:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NJl-0004TA-Hh for tcpm@ietf.org; Tue, 11 Jul 2006 14:50:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2006 11:50:42 -0700 X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="433742402:sNHT6040682192" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k6BIog2L001806; Tue, 11 Jul 2006 11:50:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BIogoI003584; Tue, 11 Jul 2006 11:50:42 -0700 (PDT) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 11:50:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] [Repost] Review of the various TCP MACing proposals Date: Tue, 11 Jul 2006 11:50:39 -0700 Message-ID: <362EE5760826E94CAA9D7C3022B4A92302645A01@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] [Repost] Review of the various TCP MACing proposals Thread-Index: AcakPsmQat0RWOPjTEO/cn2As6kZJgAKtHrA From: "Sriram Viswanathan \(sriram_v\)" To: "Joe Touch" , "EKR" X-OriginalArrivalTime: 11 Jul 2006 18:50:42.0520 (UTC) FILETIME=[E91A8580:01C6A51A] DKIM-Signature: a=rsa-sha1; q=dns; l=5764; t=1152643842; x=1153507842; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sriram_v@cisco.com; z=From:=22Sriram=20Viswanathan=20\(sriram_v\)=22=20 |Subject:RE=3A=20[tcpm]=20[Repost]=20Review=20of=20the=20various=20TCP=20MACing=2 0proposals; X=v=3Dcisco.com=3B=20h=3DWPB44psHH1U7gZyVcu8OzEvBZOs=3D; b=H3tmoyDA6F3f7yia5SgWtums/8vz1rQD2CiAjk+1IUYJUBOgN5ggaLEAKR9343QClyt4em/Q mhxFEVejlEsaciVi9HukQ0XrnRC+s/YsyuxqYZVTSc8g4m2AziX2/dWI; Authentication-Results: sj-dkim-2.cisco.com; header.From=sriram_v@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > > A number of common issues come up here: > >=20 > > - Use of key identifiers: One natural way to support key rollover > > is to incorporate a key (or association) identifier. This=20 > > allows the receiving party to determine which key was used > > to protect the received segment. It also provides a potential > > hook for external key management, e.g., via IKE. >=20 > Where is that key ID in IPsec AH? >=20 > There's only an SPI, the SPI indexes a database with the key=20 > ID, which can change via a separate (IKE) protocol. >=20 > In TCP-SA (simple-auth), we use the same principle: > where SPI -> socket pair (IP pair, port pair) >=20 > > - Trial Authentication: If multiple parallel keys are used for > > rollover and a key identifier is not used, then the receiver > > potentially needs to try all the available keys. Concerns > > have been raised about the potential for computation-based > > DoS in such systems. >=20 > How is this handled in IPsec/IKE? With IPSec, the unique SPI for each of the SA obviates the need for multiple checks.=20 With multiple parallel keys, or during the key transition window (when both the current SA is within lifetime, and the new SA established), the SPI is the unique identifier here.=20 For TCP-SA, SPI interpretation as socket pair(IP pair, port pair) will not be unique for the session. Restarting the session to generate a different tuple pair is not acceptable. To avoid multiple checks, TCP would have to carry the equivalence of SPI - keyid is one prime example. Thanks, Sriram >=20 > > - Replacement of MAC algorithm: One way to address issues > > (1) and (2) above is to replace the current construction > > with a more modern one such as HMAC. There are actually > > two issues here, the construction and the underlying > > digest. > ... > > draft-touch-tcpm-tcp-simple-auth-01 > > ----------------------------------- > > This draft is a replacement for RFC 2385 which allows pluggable MAC=20 > > algorithms, integrity for the TCP options, and some support for=20 > > rekeying (see below). It also provides for more explicit=20 > detail about=20 > > the interface of the option with TCP. > > Otherwise, it is very similar to RFC 2385. > >=20 > > I have two major comments about this draft: > >=20 > > 1. Although the MAC algorithms are pluggable, the default is > > HMAC-MD5-96. Given the current status of MD5, I don't=20 > > believe that the IETF should be standardizing any MD5-based > > algorithms.=20 >=20 > The issues with MD5 are constrained to non-HMAC uses. The=20 > security community, AFAICT still suggests HMAC-MD5. HMAC-MD5=20 > is much faster than > HMAC-SHA1 >=20 > > 2. I'm not convinced that the rekeying strategy described > > here is OK. > >=20 > > Note that TCP-SA's support for rekeying is designed to=20 > be minimal. As=20 > > with the IPsec suite, segments carry only enough context=20 > to identify=20 > > the security association [RFC4301][RFC4306]. In TCP-SA,=20 > this context=20 > > is provided by the socket pair (IP addresses and ports=20 > for source and=20 > > destination). The key is identified only in the LSAD,=20 > and coordinated=20 > > by a separate mechanism not specified in TCP-SA. This=20 > differs from=20 > > recent approaches that assume an additional key ID field=20 > and require=20 > > support for multiple concurrently active keys on a=20 > single association=20 > > [Be06][Bo06][We05][We06]. Such complexity is not=20 > necessary in TCP-SA=20 > > because TCP is already robust to segment loss.=20 > >=20 > > ISTM that this only works properly if the key changes are=20 > more or less=20 > > synchronized. Consider what happens in the following sequence of=20 > > events: > >=20 > > 0s A and B are using K1 > > 10s A changes to K2 > > 60s A sends data packet > > > > 600s A gives up and aborts the connection (assume a=20 > total timeout > > of 9 minutes) > > 601s B changes to K2 >=20 > We do assume rough synchronization, and note that there will=20 > be packet loss during the rollover. A key resynch that spans=20 > 9 minutes will break lots of things. >=20 > > So, the maximum time difference between A and B rekeying has to be=20 > > less than the total timeout. This is plausible with automatic=20 > > rekeying, but in cases where it's manual seems difficult.=20 > What happens=20 > > when A calls B and says "rekey now" but then B decides to=20 > go get a cup=20 > > of coffee before rekeying? Obviously, it can be made to=20 > work, but it=20 > > seems undesirable. >=20 > That depends on the implementation of the LSAD updates; one=20 > can design the implementation to make new keys active at a=20 > scheduled time in the future. That means that the clocktime=20 > on each system then becomes a security issue, though. >=20 > > In order to allow longer gaps between rekeying on the two=20 > sides, you=20 > > need to support multiple parallel keys. > >=20 > > SUMMARY OF PROPOSALS > > -------------------- > > Be06 BWLVW06 TA06 > > -------------------------------- > > Key Identifiers No Yes No > > Trial Authentication Yes No No > > New MAC No Yes Yes >=20 > This summary doesn't address the need for integrated key=20 > management, the effect on TCP's timers and window=20 > mechanisms, and the impact on TCP's state diagrams. IMO,=20 > those are as - if not more - important considerations. >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 11 14:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NSQ-0002Jk-RJ; Tue, 11 Jul 2006 14:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NSQ-0002JR-CM for tcpm@ietf.org; Tue, 11 Jul 2006 14:59:42 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NSP-0004sJ-0N for tcpm@ietf.org; Tue, 11 Jul 2006 14:59:42 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6BIwuH23181; Tue, 11 Jul 2006 11:58:57 -0700 (PDT) Message-ID: <44B3F4E9.1080901@isi.edu> Date: Tue, 11 Jul 2006 11:58:49 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Sriram Viswanathan (sriram_v)" Subject: Re: [tcpm] [Repost] Review of the various TCP MACing proposals References: <362EE5760826E94CAA9D7C3022B4A92302645A01@xmb-sjc-224.amer.cisco.com> In-Reply-To: <362EE5760826E94CAA9D7C3022B4A92302645A01@xmb-sjc-224.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1328613646==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1328613646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD802DD75A7D10290F741D7E9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD802DD75A7D10290F741D7E9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sriram Viswanathan (sriram_v) wrote: > =20 >>> A number of common issues come up here: >>> >>> - Use of key identifiers: One natural way to support key rollover >>> is to incorporate a key (or association) identifier. This=20 >>> allows the receiving party to determine which key was used >>> to protect the received segment. It also provides a potential >>> hook for external key management, e.g., via IKE. >> Where is that key ID in IPsec AH? >> >> There's only an SPI, the SPI indexes a database with the key=20 >> ID, which can change via a separate (IKE) protocol. >> >> In TCP-SA (simple-auth), we use the same principle: >> where SPI -> socket pair (IP pair, port pair) >> >>> - Trial Authentication: If multiple parallel keys are used for >>> rollover and a key identifier is not used, then the receiver >>> potentially needs to try all the available keys. Concerns >>> have been raised about the potential for computation-based >>> DoS in such systems. >> How is this handled in IPsec/IKE? >=20 > With IPSec, the unique SPI for each of the SA obviates the need for > multiple checks.=20 > With multiple parallel keys, or during the key transition window (when > both the current SA is within lifetime, and the new SA established), th= e > SPI is the unique identifier here.=20 I talked with Allison and Steve Bellovin this AM. The key here is whether we care about dropped packets during the transition. If not, we can save some bytes. If so, we should add an ID-extender field. I say ID-extender because the tuple would be: TCP socket pair, ID-extender I.e., the ID-extender is NOT just a key ID; it's an ID within this connection ID. > For TCP-SA, SPI interpretation as socket pair(IP pair, port pair) will= > not be unique for the session. Restarting the session to generate a > different tuple pair is not acceptable. > To avoid multiple checks, TCP would have to carry the equivalence of SP= I > - keyid is one prime example. As per above, we don't need a full SPI; the socket pair is still the primary identifier. Joe --------------enigD802DD75A7D10290F741D7E9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs/TpE5f5cImnZrsRAoTMAJ9ZtPl/Iks4GRnAUcSGhSiwB5yYLACgsiG+ qz7HOJbthi2EkuQd5iWa+UA= =yyOK -----END PGP SIGNATURE----- --------------enigD802DD75A7D10290F741D7E9-- --===============1328613646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1328613646==-- From tcpm-bounces@ietf.org Tue Jul 11 17:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Q35-0001RX-KM; Tue, 11 Jul 2006 17:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Q33-0001RO-NY for tcpm@ietf.org; Tue, 11 Jul 2006 17:45:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Q32-0007Mx-Er for tcpm@ietf.org; Tue, 11 Jul 2006 17:45:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 13:49:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="31870776:sNHT28832584" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BKnQt3018440; Tue, 11 Jul 2006 16:49:26 -0400 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6BKmYPR017623; Tue, 11 Jul 2006 13:49:26 -0700 (PDT) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 13:49:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] [Repost] Review of the various TCP MACing proposals Date: Tue, 11 Jul 2006 13:49:20 -0700 Message-ID: <362EE5760826E94CAA9D7C3022B4A92302645AA4@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] [Repost] Review of the various TCP MACing proposals Thread-Index: AcalH7eYH9p66OAdQISEeS2SUL8HjAAB4rbg From: "Sriram Viswanathan \(sriram_v\)" To: "Joe Touch" X-OriginalArrivalTime: 11 Jul 2006 20:49:21.0973 (UTC) FILETIME=[7CA0D650:01C6A52B] DKIM-Signature: a=rsa-sha1; q=dns; l=2580; t=1152650966; x=1153514966; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sriram_v@cisco.com; z=From:=22Sriram=20Viswanathan=20\(sriram_v\)=22=20 |Subject:RE=3A=20[tcpm]=20[Repost]=20Review=20of=20the=20various=20TCP=20MACing=2 0proposals |To:=22Joe=20Touch=22=20; X=v=3Dcisco.com=3B=20h=3DWPB44psHH1U7gZyVcu8OzEvBZOs=3D; b=0W2t93XmZFNFOMXilZgz1dNNaP0DPmey75tSstMAiKeWZK4T+KJC/xBswszJE7HZjVPVnq2P nZpu5hvhagaX7UT+ve7BMgJSuhzGVA0VoI2+IdGtj+A54nYlIgNF1oty; Authentication-Results: rtp-dkim-2.cisco.com; header.From=sriram_v@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 >=20 > Sriram Viswanathan (sriram_v) wrote: > > =20 > >>> A number of common issues come up here: > >>> > >>> - Use of key identifiers: One natural way to support key rollover > >>> is to incorporate a key (or association) identifier. This=20 > >>> allows the receiving party to determine which key was used > >>> to protect the received segment. It also provides a potential > >>> hook for external key management, e.g., via IKE. > >> Where is that key ID in IPsec AH? > >> > >> There's only an SPI, the SPI indexes a database with the key ID,=20 > >> which can change via a separate (IKE) protocol. > >> > >> In TCP-SA (simple-auth), we use the same principle: > >> where SPI -> socket pair (IP pair, port pair) > >> > >>> - Trial Authentication: If multiple parallel keys are used for > >>> rollover and a key identifier is not used, then the receiver > >>> potentially needs to try all the available keys. Concerns > >>> have been raised about the potential for computation-based > >>> DoS in such systems. > >> How is this handled in IPsec/IKE? > >=20 > > With IPSec, the unique SPI for each of the SA obviates the need for=20 > > multiple checks. > > With multiple parallel keys, or during the key transition=20 > window (when=20 > > both the current SA is within lifetime, and the new SA=20 > established),=20 > > the SPI is the unique identifier here. >=20 > I talked with Allison and Steve Bellovin this AM. The key=20 > here is whether we care about dropped packets during the=20 > transition. If not, we can save some bytes. >=20 > If so, we should add an ID-extender field. I say ID-extender=20 > because the tuple would be: > TCP socket pair, ID-extender >=20 > I.e., the ID-extender is NOT just a key ID; it's an ID within=20 > this connection ID. How would you specify this ID-extender? If this is marked explictly on-the-wire, it brings in the need for the ID-extender to be symmetric (or understood) at both endpoints. That would conceptually be identical to the usage of the keyid. Thanks, Sriram >=20 > > For TCP-SA, SPI interpretation as socket pair(IP pair, port pair)=20 > > will not be unique for the session. Restarting the session=20 > to generate=20 > > a different tuple pair is not acceptable. >=20 > > To avoid multiple checks, TCP would have to carry the=20 > equivalence of=20 > > SPI > > - keyid is one prime example. >=20 > As per above, we don't need a full SPI; the socket pair is=20 > still the primary identifier. >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 11 18:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0QyG-0002XO-BH; Tue, 11 Jul 2006 18:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0QyF-0002XB-K9 for tcpm@ietf.org; Tue, 11 Jul 2006 18:44:47 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0QyE-0001Ty-99 for tcpm@ietf.org; Tue, 11 Jul 2006 18:44:47 -0400 Received: from [128.9.176.211] (c2-vpn02.isi.edu [128.9.176.211]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6BMi8H24386; Tue, 11 Jul 2006 15:44:08 -0700 (PDT) Message-ID: <44B429B1.3060509@isi.edu> Date: Tue, 11 Jul 2006 15:44:01 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Sriram Viswanathan (sriram_v)" Subject: Re: [tcpm] [Repost] Review of the various TCP MACing proposals References: <362EE5760826E94CAA9D7C3022B4A92302645AA4@xmb-sjc-224.amer.cisco.com> In-Reply-To: <362EE5760826E94CAA9D7C3022B4A92302645AA4@xmb-sjc-224.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1860038002==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1860038002== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4C41EE197265081554FF094" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4C41EE197265081554FF094 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sriram Viswanathan (sriram_v) wrote: >> I talked with Allison and Steve Bellovin this AM. The key=20 >> here is whether we care about dropped packets during the=20 >> transition. If not, we can save some bytes. >> >> If so, we should add an ID-extender field. I say ID-extender=20 >> because the tuple would be: >> TCP socket pair, ID-extender >> >> I.e., the ID-extender is NOT just a key ID; it's an ID within=20 >> this connection ID. >=20 > How would you specify this ID-extender? If this is marked explictly > on-the-wire, it brings in the need for the ID-extender to be symmetric > (or understood) at both endpoints. That would conceptually be identica= l > to the usage of the keyid. The tuple specifies all the parameters; when the tuple changes, ANY parameter could change, i.e., key, algorithm, which header fields are covered, etc. See the I-D on this point; the LSAD contains the info, and the tuple is the index to the LSAD. There is a utility to allow the tuple to change within a connection - thus the ID-extender. There is no need to associate that extender with any particular LSAD component. Joe --------------enigF4C41EE197265081554FF094 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtCmxE5f5cImnZrsRAit6AJ4nh2dIsbBecVwN48ZQwXfAyhwHKQCg1ugx yIM38jurSwuXWSbJrarNwM8= =OlGX -----END PGP SIGNATURE----- --------------enigF4C41EE197265081554FF094-- --===============1860038002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1860038002==-- From tcpm-bounces@ietf.org Thu Jul 13 13:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zk-0001pi-E7; Thu, 13 Jul 2006 13:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zi-0001nJ-EO for tcpm@ietf.org; Thu, 13 Jul 2006 13:28:58 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14zg-0000EX-2F for tcpm@ietf.org; Thu, 13 Jul 2006 13:28:58 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DHSHH22103; Thu, 13 Jul 2006 10:28:17 -0700 (PDT) Message-ID: <44B682AB.9010702@isi.edu> Date: Thu, 13 Jul 2006 10:28:11 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [tcpm] feedcback on tcp-secure-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559540400==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1559540400== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig131F90EF6D0F040801F3B907" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig131F90EF6D0F040801F3B907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had the following comments on v05. Joe -------- The doc continues to have a detailed but somewhat incomplete discussion of the attack scenario; the point of tcp-antispoof was to provide a much more detailed version of that discussion that should not be recapitulated but rather cited. The doc cites a *very* old version of tcp-antispoof, too. No reasoning is given for numeric limits to ACK throttling (why 10 in 5 seconds? why not a ratio of the number of conventional ACKs provided) TCP-MD5 isn't considered as a useful protection from these attacks (and it is). The use of both IPsec-AH and IPsec-ESP is suggested for on-path attacks, where only one of the two is required. The doc should also indicate that preventing these attacks does NOT prevent ICMP attacks (and cite Gont's draft in this regard); it would be useful for the security considerations to address whether ICMPs should be blocked altogether and what the impact of that would be. Without such blocking, it's not clear what the utility of this solution would be. The middlebox considerations (sec 8.1) declare that some behavior is noncompliant, but don't consider whether it already exists and how to make their system avoid ACK wars that might result (e.g., to detect and quench such a war, which seems separate from ACK throtling per se). ----------------------------------------- THIS IS THE BIG POINT REGARDING REVISION: The specific modifications suggested are given as loosely discussed recipes rather than a specific list of the modifications to TCP; IMO, the latter should be required. ----------------------------------------- The blind data injection attack suggests that the window of vulnerability can be as large as the amount of unacknowledged data, which can be as large as the window. This means that even if the RST attack is reduced from a fraction of the windowsize to 1, a similarly detrimental attack can still occur from data injection. This needs to be discussed in the security considerations, and continues to render the utility of the RST protection of limited comparable value. --------------enig131F90EF6D0F040801F3B907 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtoKrE5f5cImnZrsRAjE/AKDpERiHZaugHNWmUY6829LezI4ANQCgru58 nnWDnbESAGezJIYE35ZbsYo= =WKCm -----END PGP SIGNATURE----- --------------enig131F90EF6D0F040801F3B907-- --===============1559540400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1559540400==-- From tcpm-bounces@ietf.org Thu Jul 13 13:44:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Ec-000071-Pw; Thu, 13 Jul 2006 13:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Eb-00006w-Dl for tcpm@ietf.org; Thu, 13 Jul 2006 13:44:21 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15Ea-00014J-T4 for tcpm@ietf.org; Thu, 13 Jul 2006 13:44:21 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6DHiHpK008965 for ; Thu, 13 Jul 2006 20:44:17 +0300 Date: Thu, 13 Jul 2006 20:44:17 +0300 (EEST) From: Pekka Savola To: tcpm@ietf.org Subject: Re: [tcpm] feedcback on tcp-secure-05 In-Reply-To: <44B682AB.9010702@isi.edu> Message-ID: References: <44B682AB.9010702@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1594/Wed Jul 12 18:04:34 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Note: I have not read the spec. I'd intend to do it once it gets into WGLC. But some follow-up to some of Joe's points below, On Thu, 13 Jul 2006, Joe Touch wrote: > The doc continues to have a detailed but somewhat incomplete discussion > of the attack scenario; the point of tcp-antispoof was to provide a much > more detailed version of that discussion that should not be > recapitulated but rather cited. You couldn't just simply cite it without any summary though, as antispoof is heading Informational, and doing so would likely require a down-ref. > No reasoning is given for numeric limits to ACK throttling (why 10 in 5 > seconds? why not a ratio of the number of conventional ACKs provided) Simpler to implement, maybe? > The doc should also indicate that preventing these attacks does NOT > prevent ICMP attacks (and cite Gont's draft in this regard); it would be > useful for the security considerations to address whether ICMPs should > be blocked altogether and what the impact of that would be. Without such > blocking, it's not clear what the utility of this solution would be. First of all, your last comment is correct only in isolation, i.e., when ICMP attack protections have not been implemented but this is. In reality, all vendors have implemented ICMP attack protections for at least about 1.5 years. I do no think this document should be saying anything about blocking ICMPs. On the other hand, reference to ICMP attacks would probably make sense. Whether there should be more extensive discussion of ICMP attacks might or might not make sense, depending on the how heavily this doc would depend on the security discussion of tcp-antispoof. > The specific modifications suggested are given as loosely discussed > recipes rather than a specific list of the modifications to TCP; IMO, > the latter should be required. I'd agree that specific modifications would likely be preferable. In section 3.2 the text says: Instead, this document requires that implementations MUST perform the following steps in place of those specified in [RFC0793](listed above). Just to be clear, I'd rather say: Instead, this document requires that implementations that implement this specification MUST perform the following steps in place of those specified in [RFC0793](listed above). or something like that. This doc is not making the behaviour of 793 incompliant, surely. But rather introducing a specification that, if implemented, must be done in a certain way. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 13:48:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Iq-0002DR-Jm; Thu, 13 Jul 2006 13:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Ip-0002DM-51 for tcpm@ietf.org; Thu, 13 Jul 2006 13:48:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15In-0001IS-Fj for tcpm@ietf.org; Thu, 13 Jul 2006 13:48:43 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 10:48:41 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DHmep5028534 for ; Thu, 13 Jul 2006 10:48:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6DHme2D016011 for ; Thu, 13 Jul 2006 10:48:40 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 10:48:40 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 10:48:40 -0700 Message-ID: <44B6877B.6070004@cisco.com> Date: Thu, 13 Jul 2006 13:48:43 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/mixed; boundary="------------080502000804040005080404" X-OriginalArrivalTime: 13 Jul 2006 17:48:40.0561 (UTC) FILETIME=[93782610:01C6A6A4] DKIM-Signature: a=rsa-sha1; q=dns; l=8291; t=1152812920; x=1153676920; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:[Fwd=3A=20Re=3A=20tcpsecure]; X=v=3Dcisco.com=3B=20h=3DE1tdzOUTbWHF3+IYOQpULDXrQnA=3D; b=OQo7cXb5vmXxUSBp36LzUP8hBrYxacdiRRd5s+zaBW+FhsZ0aeQM3ysphnUrcYnHBIAeJkK6 QTHmPdkNjjd3S7nG36IvNwkXZ2FVWN6Ix3lIjoyS0FBVJylpCK0/7zbe; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Subject: [tcpm] [Fwd: Re: tcpsecure] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------080502000804040005080404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit These are Joes original comments to V04 of tcp-secure... From which minor changes were made to make V05.. Joe, you might want to add more/or what have you... possibly send text please :=0 R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) --------------080502000804040005080404 Content-Type: message/rfc822; name="Re: tcpsecure" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: tcpsecure" Received: from xbh-rtp-201.amer.cisco.com ([64.102.31.12]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 14:18:31 -0500 Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 14:18:31 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 11:18:30 -0800 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2006 11:18:30 -0800 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2TJI2ZT005606 for ; Wed, 29 Mar 2006 11:18:30 -0800 (PST) Received: from boreas.isi.edu ([128.9.160.161]) by sj-inbound-d.cisco.com with ESMTP; 29 Mar 2006 11:18:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="255782183:sNHT25309596" Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2TJGdG20669; Wed, 29 Mar 2006 11:16:39 -0800 (PST) Message-ID: <442ADC9D.8090203@isi.edu> Date: Wed, 29 Mar 2006 11:14:37 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Randall Stewart CC: mallman@icir.org, Ted Faber Subject: Re: tcpsecure References: <20060329024046.BB1013EAC43@lawyers.icir.org> <442A615B.5080902@cisco.com> In-Reply-To: <442A615B.5080902@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Return-Path: touch@ISI.EDU X-OriginalArrivalTime: 29 Mar 2006 19:18:30.0560 (UTC) FILETIME=[905F3A00:01C65365] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randall Stewart wrote: > Mark Allman wrote: >> >> Randall- >> Not sure if Touch caught you in Dallas, but when I sat and chatted with >> him he had a bunch of pretty minor things flagged in tcpsecure. He said >> they weren't hugely technical, but should be fixed. If you didn't chat >> with him can you ping him? FYI, here they are. It's minor in the sense that I see where the doc could go now; the doc does need some substantial work, but the solution doesn't (except w.r.t. one part; see below). Joe - ---- A. the doc describes 3 different mods 1. RST 2. SYN 3. data injection It'd be useful to explain what the common thread is, and why all three are needed. RST and SYN fall into the same "short run for a long slide" category. The data injection stuff seems out of place, though. The solution is comparatively cumbersome and I don't believe as well agreed. It's also a bit misnamed (it's really a blind window sliding attack), and blind data injection is still fairly simple (in-window). B. the general document writing and presentation needs work including spelling, sentence structure, etc. C. I would suggest a more focused discussion as follows: a. section 1 should summarize tcp-antispoof in a paragraph or two, but otherwise ref off to that instead, it should focus on a few things: 1. how a TCP solution is different 2. why the group of mods to TCP are all related 3. why modifying TCP here is a good thing I would agree that cleaning up unintended holes in TCP processing is reasonable, esp. given the small mods that can accomplish them (e.g., for RST and SYN). I would prefer if that were the focus of the doc (safety from incorrect messages, regardless of intent) , with the side effect of increasing resistance to some recent attacks, BUT that if real protection is required, that real security is recommended (e.g., IPsec). Where increased resistance is described ("much harder"), it should be quantified. b. the protocol sections should discuss things 793-style Some of the discussion of the changes seems more like a recipe than a protocol spec change. Specific portions of 793 should be quoted where needed, and changes clearly indicated. These should be entitled "Changes to 793" or somesuch, rather than 'Mitigation'. c. section 5- the blind data stuff, is "too long a walk for a short slide" It requires new TCB state (MAX.SND.WND) which is very informally introduced, and not discussed: - do you save the window scale for that max? - does this present an opportunity for attack itself? While this protects from some ACK attacks, it's still sufficiently easy, after this mod, to inject ACKs that accomplish the same purpose, or to inject data similarly. I would recommend removing it. D. ACK throttling needs a more clear discussion The requirements need to be separated and condensed as a list, rather than dispersed througout (the same recommendation applies to other sections, BTW). The potential for implementation deadlock deserves much more than a passing reference; this is a substantial concern. If there's a way around it, it should be discussed. It seems incumbent to me that this solution MUST ;-) specify the protocol behavior in such a way that such deadlocks are not possible. (793 does this all over the place, by placing rules on the order of handling queued segments, order of handling signals, data, etc., etc.) E. the backward compatibility section needs to highlight a few more things: - - when incrementally or mutually deployed (separate discussions): - which sides benefit and how - which sides are impacted and how - is there any impact or benefit to third parties middlebox considerations are a subsection of backward compatibility, IMO I would suggest that mboxes that modify TCP packets are briefly described as "deserving what they get" rather than going into details. What some mboxes do is irrelevant; more to the point is what we can expect a mbox to do, and that's not really static anyway (unless you refer off to the RFC defining the versions, like half-cone, full-cone, etc.) Finally, I would suggest that protection from mbox interference is better provided by IPsec (which would interfere with mbox mod of the packets). ;-) Interoperability reports seem like at best an appendix, but more like something that would accompany the submission of this doc as standards-track. It doesn't seem like it ought to be inside the doc. F. security considerations should address the benefits vs limits in specific - how much more security is provided, and what are the limits. it should also note that on-path attacks are still possible, and that data injection attacks are still possible. it should finally note that full protection warrants the use of IPsec (that's what security consids are for!) if there are still deadlocks possible that can be triggered by malicious parties, then that needs to be noted here too G. section 12 ought to note the input of the TCPM WG, and a few names there if you feel appropriate. This work was, IMO, polished by the WG a bit since I first saw it (e.g., the need for ACK throttling), and that too should (IMO) be noted. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKtydE5f5cImnZrsRAmtsAKCs68nm0tYjtYM/6OuJFKrEpbN78ACg8cmr WBNSI1GxpVS4xkdh7FM+qOQ= =LA/R -----END PGP SIGNATURE----- --------------080502000804040005080404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------080502000804040005080404-- From tcpm-bounces@ietf.org Thu Jul 13 13:53:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Nv-0007ng-Em; Thu, 13 Jul 2006 13:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Ns-0007nR-Qb for tcpm@ietf.org; Thu, 13 Jul 2006 13:53:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15Nr-0001jq-GX for tcpm@ietf.org; Thu, 13 Jul 2006 13:53:56 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DHrJH28163; Thu, 13 Jul 2006 10:53:19 -0700 (PDT) Message-ID: <44B68888.1070207@isi.edu> Date: Thu, 13 Jul 2006 10:53:12 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Randall Stewart Subject: Re: [tcpm] [Fwd: Re: tcpsecure] References: <44B6877B.6070004@cisco.com> In-Reply-To: <44B6877B.6070004@cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0658756883==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0658756883== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2910210CA1D593B8DAB49324" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2910210CA1D593B8DAB49324 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randall Stewart wrote: > These are Joes original comments to > V04 of tcp-secure... >=20 > From which minor changes were made to make V05.. >=20 >=20 > Joe, you might want to add more/or what have you... > possibly send text please :=3D0 >=20 > R I sent them already. IMO the changes from 04 to 05 were very cosmetic. Joe --------------enig2910210CA1D593B8DAB49324 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtoiIE5f5cImnZrsRApLqAKCANIWBpw4OfnMH09KH2LkNw/pFbwCeNtJp NFTbgEsSlLfYBJm/UmjzGXQ= =VsG1 -----END PGP SIGNATURE----- --------------enig2910210CA1D593B8DAB49324-- --===============0658756883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0658756883==-- From tcpm-bounces@ietf.org Thu Jul 13 13:54:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15OB-0007sJ-2Y; Thu, 13 Jul 2006 13:54:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15O9-0007sE-Ur for tcpm@ietf.org; Thu, 13 Jul 2006 13:54:13 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15O7-0001jq-Jc for tcpm@ietf.org; Thu, 13 Jul 2006 13:54:13 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DHpqH27935; Thu, 13 Jul 2006 10:51:52 -0700 (PDT) Message-ID: <44B68831.5000307@isi.edu> Date: Thu, 13 Jul 2006 10:51:45 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0798123534==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0798123534== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF58B14092CAD9CF03F5D1330" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF58B14092CAD9CF03F5D1330 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > Note: I have not read the spec. I'd intend to do it once it gets into > WGLC. But some follow-up to some of Joe's points below, >=20 > On Thu, 13 Jul 2006, Joe Touch wrote: >> The doc continues to have a detailed but somewhat incomplete discussio= n >> of the attack scenario; the point of tcp-antispoof was to provide a mu= ch >> more detailed version of that discussion that should not be >> recapitulated but rather cited. >=20 > You couldn't just simply cite it without any summary though, as > antispoof is heading Informational, and doing so would likely require a= > down-ref. It's not a down ref to cite an informational document informationally ;-)= >> No reasoning is given for numeric limits to ACK throttling (why 10 in = 5 >> seconds? why not a ratio of the number of conventional ACKs provided) >=20 > Simpler to implement, maybe? Sure, a fixed number is simpler, but a reason for the specific numbers would be useful too. Joe --------------enigF58B14092CAD9CF03F5D1330 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtogxE5f5cImnZrsRAp7KAKCzthTD0rUMR8uVORC5OoGOULg4mgCfdUhD 3UYM4rCMvcQrebzgNSSP1xw= =2W+U -----END PGP SIGNATURE----- --------------enigF58B14092CAD9CF03F5D1330-- --===============0798123534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0798123534==-- From tcpm-bounces@ietf.org Thu Jul 13 13:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15QM-00089l-14; Thu, 13 Jul 2006 13:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15QK-00089f-FO for tcpm@ietf.org; Thu, 13 Jul 2006 13:56:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15QJ-0001vi-6T for tcpm@ietf.org; Thu, 13 Jul 2006 13:56:28 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 10:56:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DHuPvJ006607; Thu, 13 Jul 2006 10:56:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DHuOJs024630; Thu, 13 Jul 2006 10:56:25 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 10:56:22 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 10:56:21 -0700 Message-ID: <44B68945.3000504@cisco.com> Date: Thu, 13 Jul 2006 13:56:21 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] [Fwd: Re: tcpsecure] References: <44B6877B.6070004@cisco.com> <44B68888.1070207@isi.edu> In-Reply-To: <44B68888.1070207@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 17:56:21.0881 (UTC) FILETIME=[A66FFE90:01C6A6A5] DKIM-Signature: a=rsa-sha1; q=dns; l=476; t=1152813385; x=1153677385; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20[Fwd=3A=20Re=3A=20tcpsecure]; X=v=3Dcisco.com=3B=20h=3DqLBiZC82pFTu+ck7rGYGWzdO08g=3D; b=DiNHWFxJfpkqEOcO8pCl5IkLfo9WZvNXu/9qvdiTCrnp9Ipqda5t09NZnjr0AqeeP7K4pcZ6 MWouYzLE2xqyHklWJM5sB1F172Z6KLkNEAfBMJIdMK7QqECmp02ola9D; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > > Randall Stewart wrote: > >>These are Joes original comments to >>V04 of tcp-secure... >> >>From which minor changes were made to make V05.. >> >> >>Joe, you might want to add more/or what have you... >>possibly send text please :=0 >> >>R > > > I sent them already. IMO the changes from 04 to 05 were very cosmetic. > I agree... R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 13:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Rf-0008Js-SD; Thu, 13 Jul 2006 13:57:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Rd-0008Jk-AE for tcpm@ietf.org; Thu, 13 Jul 2006 13:57:49 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15Rc-00020H-SK for tcpm@ietf.org; Thu, 13 Jul 2006 13:57:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6DHvlHs009322; Thu, 13 Jul 2006 20:57:47 +0300 Date: Thu, 13 Jul 2006 20:57:47 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] feedcback on tcp-secure-05 In-Reply-To: <44B68831.5000307@isi.edu> Message-ID: References: <44B682AB.9010702@isi.edu> <44B68831.5000307@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1594/Wed Jul 12 18:04:34 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, 13 Jul 2006, Joe Touch wrote: >> On Thu, 13 Jul 2006, Joe Touch wrote: >>> The doc continues to have a detailed but somewhat incomplete discussion >>> of the attack scenario; the point of tcp-antispoof was to provide a much >>> more detailed version of that discussion that should not be >>> recapitulated but rather cited. >> >> You couldn't just simply cite it without any summary though, as >> antispoof is heading Informational, and doing so would likely require a >> down-ref. > > It's not a down ref to cite an informational document informationally ;-) Sure. But an Informative reference needs to refer to _additional_ information, not _replace_ information. So, with an informative reference you will need to have at least short summary (a paragraph) of the issues. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 14:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15UI-0000FW-Ek; Thu, 13 Jul 2006 14:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15UG-0000FG-Hi for tcpm@ietf.org; Thu, 13 Jul 2006 14:00:32 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15UF-000262-82 for tcpm@ietf.org; Thu, 13 Jul 2006 14:00:32 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2006 11:00:31 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="328895525:sNHT25685824" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DI0UWj012020; Thu, 13 Jul 2006 11:00:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DI0OK6028274; Thu, 13 Jul 2006 11:00:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 11:00:26 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 11:00:25 -0700 Message-ID: <44B68A3C.5000506@cisco.com> Date: Thu, 13 Jul 2006 14:00:28 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> <44B68831.5000307@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 18:00:26.0092 (UTC) FILETIME=[37FFA2C0:01C6A6A6] DKIM-Signature: a=rsa-sha1; q=dns; l=1215; t=1152813630; x=1153677630; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DEKS6OTHN/UpTjOxfSf0GHsnvOQo=3D; b=bLZMqRbYNMG1g97Bb9GGllvNnXHuEJU8SPTr45kazhxauzNGpsdXDNlmAduRP7pxCdiqJzvC 1SMMoxebhU4wIH4+iCHSQLuEs32+6+MzF6ewta+LH0YhJeoSJYg7dU4H; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Pekka Savola wrote: > On Thu, 13 Jul 2006, Joe Touch wrote: > >>> On Thu, 13 Jul 2006, Joe Touch wrote: >>> >>>> The doc continues to have a detailed but somewhat incomplete discussion >>>> of the attack scenario; the point of tcp-antispoof was to provide a >>>> much >>>> more detailed version of that discussion that should not be >>>> recapitulated but rather cited. >>> >>> >>> You couldn't just simply cite it without any summary though, as >>> antispoof is heading Informational, and doing so would likely require a >>> down-ref. >> >> >> It's not a down ref to cite an informational document informationally ;-) > > > Sure. But an Informative reference needs to refer to _additional_ > information, not _replace_ information. So, with an informative > reference you will need to have at least short summary (a paragraph) of > the issues. > Yep.. we could say something like.. For further reference information on these refer to .... Note to Joe, the older revision of anti-spoof comes right from the xml database... not sure why it did not snarf your latest version.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 14:04:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Xs-0000Zn-Ia; Thu, 13 Jul 2006 14:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15Xr-0000Zi-5M for tcpm@ietf.org; Thu, 13 Jul 2006 14:04:15 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15Xo-0002GN-NJ for tcpm@ietf.org; Thu, 13 Jul 2006 14:04:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2006 11:04:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DI4BVQ003577; Thu, 13 Jul 2006 11:04:11 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6DI4BiF029570; Thu, 13 Jul 2006 11:04:11 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 11:04:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05 Date: Thu, 13 Jul 2006 11:04:10 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05 Thread-Index: Acamod+jMcjqUlXVR1CvUlk9erxuKQAALgng From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" , X-OriginalArrivalTime: 13 Jul 2006 18:04:11.0699 (UTC) FILETIME=[BE788830:01C6A6A6] DKIM-Signature: a=rsa-sha1; q=dns; l=3878; t=1152813851; x=1153677851; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DCeksYhPTKiajql2H6p2yZiTQwso=3D; b=b7kj3BV3F2b1EbC5WItHkdOIUrWqLUs32RjzLuqP/mmsRjK5oshpJZVjAe9yMr7+BdwjngVx mvlzAghI28O5exHopb9v+1JYrRpkYHzM5B7aNUArTdhMpefxHe0xabS2; Authentication-Results: sj-dkim-3.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Inline comments... > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Thursday, July 13, 2006 10:28 AM > To: tcpm@ietf.org > Subject: [tcpm] feedcback on tcp-secure-05 >=20 > I had the following comments on v05. >=20 > Joe > -------- >=20 > The doc continues to have a detailed but somewhat incomplete=20 > discussion of the attack scenario; the point of tcp-antispoof=20 > was to provide a much more detailed version of that=20 > discussion that should not be recapitulated but rather cited. >=20 > The doc cites a *very* old version of tcp-antispoof, too. Is the suggestion to take out some verbiage on the attack scenario(s) mentioned in the document. If so which sections are of concern? The comment of citing a new version of tcp-antispoof is taken and will be relected in the upcoming version. >=20 > No reasoning is given for numeric limits to ACK throttling=20 > (why 10 in 5 seconds? why not a ratio of the number of=20 > conventional ACKs provided) The reasoning given for numeric limits is by no means meant to reflect the exhaustive set of possibilities for ACK throttling. Is the suggestion to provide a complete list of ACK throttling possibilities? >=20 > TCP-MD5 isn't considered as a useful protection from these=20 > attacks (and it is). Using TCP-MD5 makes the attacks described in this document much harder than without MD5. So beats me as to why TCP-MD5 isn't useful. Can you please elaborate?=20 >=20 > The use of both IPsec-AH and IPsec-ESP is suggested for=20 > on-path attacks, where only one of the two is required. Ok. >=20 > The doc should also indicate that preventing these attacks=20 > does NOT prevent ICMP attacks (and cite Gont's draft in this=20 > regard); it would be useful for the security considerations=20 > to address whether ICMPs should be blocked altogether and=20 > what the impact of that would be. Without such blocking, it's=20 > not clear what the utility of this solution would be. Ok. >=20 > The middlebox considerations (sec 8.1) declare that some=20 > behavior is noncompliant, but don't consider whether it=20 > already exists and how to make their system avoid ACK wars=20 > that might result (e.g., to detect and quench such a war,=20 > which seems separate from ACK throtling per se). Will re-read the text and see if we can make changes in this aspect. >=20 > ----------------------------------------- > THIS IS THE BIG POINT REGARDING REVISION: >=20 > The specific modifications suggested are given as loosely=20 > discussed recipes rather than a specific list of the=20 > modifications to TCP; IMO, the latter should be required. >=20 > ----------------------------------------- "Loosely discussed recipes" couldn't parse this. Can you pl elobarate or propose some text that can be considered for addition in the next revision? >=20 > The blind data injection attack suggests that the window of=20 > vulnerability can be as large as the amount of unacknowledged=20 > data, which can be as large as the window. This means that=20 > even if the RST attack is reduced from a fraction of the=20 > windowsize to 1, a similarly detrimental attack can still=20 > occur from data injection.=20 Yes, but it depends on the application's response to the "bad data". Just to give an example : For BGP it would mean connection tear down whereas for other applications it may or may not. > This needs to be discussed in the=20 > security considerations, and continues to render the utility=20 > of the RST protection of limited comparable value. Hmm. RST protection is still needed. To put it shortly the document outlines the robustness initiatives that can performed at the transport layer (TCP) against some attacks (RST/SYN and data injection) -Anantha >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 14:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15ab-0000uZ-4a; Thu, 13 Jul 2006 14:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15aa-0000uU-K9 for tcpm@ietf.org; Thu, 13 Jul 2006 14:07:04 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15aZ-0002N1-8J for tcpm@ietf.org; Thu, 13 Jul 2006 14:07:04 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DI5tH01371; Thu, 13 Jul 2006 11:05:55 -0700 (PDT) Message-ID: <44B68B7C.4010401@isi.edu> Date: Thu, 13 Jul 2006 11:05:48 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> <44B68831.5000307@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1387846291==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1387846291== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9BEBFD35F46F05A35A6DBBAE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9BEBFD35F46F05A35A6DBBAE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Thu, 13 Jul 2006, Joe Touch wrote: >>> On Thu, 13 Jul 2006, Joe Touch wrote: >>>> The doc continues to have a detailed but somewhat incomplete discuss= ion >>>> of the attack scenario; the point of tcp-antispoof was to provide a >>>> much >>>> more detailed version of that discussion that should not be >>>> recapitulated but rather cited. >>> >>> You couldn't just simply cite it without any summary though, as >>> antispoof is heading Informational, and doing so would likely require= a >>> down-ref. >> >> It's not a down ref to cite an informational document informationally = ;-) >=20 > Sure. But an Informative reference needs to refer to _additional_ > information, not _replace_ information. So, with an informative > reference you will need to have at least short summary (a paragraph) of= > the issues. Agreed, though we're talking about background and motivation, which isn't as critical. Joe --------------enig9BEBFD35F46F05A35A6DBBAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtot8E5f5cImnZrsRAvygAJ9DqrkEqBqj5g2Z+YKv4ecDsqbtDQCeMUBd o2slPFzavFNF0wRfcqsslvQ= =MzbH -----END PGP SIGNATURE----- --------------enig9BEBFD35F46F05A35A6DBBAE-- --===============1387846291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1387846291==-- From tcpm-bounces@ietf.org Thu Jul 13 14:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15bW-00012w-JK; Thu, 13 Jul 2006 14:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15bV-00012l-1W for tcpm@ietf.org; Thu, 13 Jul 2006 14:08:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15bT-0002QM-NS for tcpm@ietf.org; Thu, 13 Jul 2006 14:08:01 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DI6mH01509; Thu, 13 Jul 2006 11:06:48 -0700 (PDT) Message-ID: <44B68BB1.90402@isi.edu> Date: Thu, 13 Jul 2006 11:06:41 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Randall Stewart Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> <44B68831.5000307@isi.edu> <44B68A3C.5000506@cisco.com> In-Reply-To: <44B68A3C.5000506@cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2086919301==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2086919301== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29856C3514B544B3BC927120" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29856C3514B544B3BC927120 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randall Stewart wrote: > Note to Joe, the older revision of anti-spoof comes right > from the xml database... not sure why it did not snarf > your latest version.. I don't use XML, so maybe they incorporate xml2rfc-based stuff more quickly? If not, it's _very_ out of date ;-) Joe --------------enig29856C3514B544B3BC927120 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtouxE5f5cImnZrsRAljRAKCoG3B33eJq0aCmYYE4N+h/8lXPLACdEcu1 OxhZO7q6HIveAdxnci4M1pM= =BTEo -----END PGP SIGNATURE----- --------------enig29856C3514B544B3BC927120-- --===============2086919301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2086919301==-- From tcpm-bounces@ietf.org Thu Jul 13 14:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15dQ-0001KC-L0; Thu, 13 Jul 2006 14:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15dO-0001K6-Ix for tcpm@ietf.org; Thu, 13 Jul 2006 14:09:58 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15dN-0002uG-7E for tcpm@ietf.org; Thu, 13 Jul 2006 14:09:58 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DI9WH02274; Thu, 13 Jul 2006 11:09:33 -0700 (PDT) Message-ID: <44B68C56.9040308@isi.edu> Date: Thu, 13 Jul 2006 11:09:26 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1292182485==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1292182485== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE8772FC2E1EE7293C6BDA09" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE8772FC2E1EE7293C6BDA09 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Inline comments... >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU]=20 >> Sent: Thursday, July 13, 2006 10:28 AM >> To: tcpm@ietf.org >> Subject: [tcpm] feedcback on tcp-secure-05 >> >> I had the following comments on v05. >> >> Joe >> -------- >> >> The doc continues to have a detailed but somewhat incomplete=20 >> discussion of the attack scenario; the point of tcp-antispoof=20 >> was to provide a much more detailed version of that=20 >> discussion that should not be recapitulated but rather cited. >> >> The doc cites a *very* old version of tcp-antispoof, too. >=20 > Is the suggestion to take out some verbiage on the attack scenario(s) > mentioned in the document. If so which sections are of concern? That should be obvious in the doc, the section that outlines the problem can be condensed to a summary paragraph and a citation. > The comment of citing a new version of tcp-antispoof is taken and will > be relected in the upcoming version. >=20 >> No reasoning is given for numeric limits to ACK throttling=20 >> (why 10 in 5 seconds? why not a ratio of the number of=20 >> conventional ACKs provided) >=20 > The reasoning given for numeric limits is by no means meant to reflect > the exhaustive set of possibilities for ACK throttling. Is the > suggestion to provide a complete list of ACK throttling possibilities? No, just to give a reason for picking the numbers 10 and 5, and whether those numbers are context-dependent or not (i.e., if some assumptions change, then would the numbers change?) >> TCP-MD5 isn't considered as a useful protection from these=20 >> attacks (and it is). >=20 > Using TCP-MD5 makes the attacks described in this document much harder > than without MD5. > So beats me as to why TCP-MD5 isn't useful. Can you please elaborate?=20 To be more clear, the document doesn't describe that TCP-MD5 solves this problem. I'm asking that the doc say what you do above. ;-) Joe --------------enigEE8772FC2E1EE7293C6BDA09 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtoxWE5f5cImnZrsRAtWdAJ0av9tSjnP8JZwUn6lWzVi3Ud/LJgCeIiEC VglvvRSQpTCAfoFbWA0d8g8= =FEl8 -----END PGP SIGNATURE----- --------------enigEE8772FC2E1EE7293C6BDA09-- --===============1292182485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1292182485==-- From tcpm-bounces@ietf.org Thu Jul 13 15:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zn-0002VL-JA; Thu, 13 Jul 2006 15:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zm-0002Rs-Bs for tcpm@ietf.org; Thu, 13 Jul 2006 15:37:10 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16x9-0002Gt-HL for tcpm@ietf.org; Thu, 13 Jul 2006 15:34:29 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k6DJYMia000337; Thu, 13 Jul 2006 12:34:22 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200607131934.k6DJYMia000337@cougar.icir.org> To: touch@isi.edu From: Sally Floyd Date: Thu, 13 Jul 2006 12:34:22 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org, Mark Handley Subject: [tcpm] feedback on draft-touch-tcp-portnames-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe - I think it would be good to add an explicit section in your draft about Service Codes in DCCP, along with a discussion of why service codes should or should not be used differently in TCP and DCCP, a comparison of the two approaches, etc. Mark Handley would be a good person to ask about the proposed use of service codes in DCCP. - Sally http://www.icir.org/floyd/ >From RFC 4340, the main DCCP RFC: Service Code: 32 bits Describes the application-level service to which the client application wants to connect. Service Codes are intended to provide information about which application protocol a connection intends to use, thus aiding middleboxes and reducing reliance on globally well-known ports. See Section 8.1.2." _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 15:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G177X-0004JN-Uu; Thu, 13 Jul 2006 15:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G177W-0004JI-Ly for tcpm@ietf.org; Thu, 13 Jul 2006 15:45:10 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G177U-0003Pm-94 for tcpm@ietf.org; Thu, 13 Jul 2006 15:45:10 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DJi4H27370; Thu, 13 Jul 2006 12:44:04 -0700 (PDT) Message-ID: <44B6A274.30606@isi.edu> Date: Thu, 13 Jul 2006 12:43:48 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sally Floyd References: <200607131934.k6DJYMia000337@cougar.icir.org> In-Reply-To: <200607131934.k6DJYMia000337@cougar.icir.org> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org, Mark Handley Subject: [tcpm] Re: feedback on draft-touch-tcp-portnames-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0860815714==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0860815714== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09AE83697832C28ABBB9828D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09AE83697832C28ABBB9828D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed - that was raised on the list already, and has been pending for the next revision. Joe Sally Floyd wrote: > Joe - >=20 > I think it would be good to add an explicit section in your draft > about Service Codes in DCCP, along with a discussion of why service > codes should or should not be used differently in TCP and DCCP, a > comparison of the two approaches, etc. Mark Handley would be a > good person to ask about the proposed use of service codes in DCCP. >=20 > - Sally > http://www.icir.org/floyd/ >=20 >>From RFC 4340, the main DCCP RFC: >=20 > Service Code: 32 bits > Describes the application-level service to which the client applica= tion > wants to connect. Service Codes are intended to provide informatio= n > about which application protocol a connection intends to use, thus > aiding middleboxes and reducing reliance on globally well-known > ports. See Section 8.1.2." --------------enig09AE83697832C28ABBB9828D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtqJ9E5f5cImnZrsRAhJEAKDFOaquj4pARZMDeQuYeNmqlfIqnQCfdG2U 8D7g30VWbLG5xNgwkwKrxqc= =nfmM -----END PGP SIGNATURE----- --------------enig09AE83697832C28ABBB9828D-- --===============0860815714== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0860815714==-- From tcpm-bounces@ietf.org Thu Jul 13 17:18:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18ZM-0007QS-IR; Thu, 13 Jul 2006 17:18:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18ZL-0007QN-J9 for tcpm@ietf.org; Thu, 13 Jul 2006 17:17:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18ZJ-0000l3-8W for tcpm@ietf.org; Thu, 13 Jul 2006 17:17:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2006 14:17:57 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="434272632:sNHT25719140" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DLHuTA030694; Thu, 13 Jul 2006 14:17:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6DLHuiB014299; Thu, 13 Jul 2006 14:17:56 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 14:17:56 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 14:17:55 -0700 Message-ID: <44B6B886.3000409@cisco.com> Date: Thu, 13 Jul 2006 17:17:58 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> <44B68831.5000307@isi.edu> <44B68A3C.5000506@cisco.com> <44B68BB1.90402@isi.edu> In-Reply-To: <44B68BB1.90402@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 21:17:56.0130 (UTC) FILETIME=[CF2BF020:01C6A6C1] DKIM-Signature: a=rsa-sha1; q=dns; l=781; t=1152825476; x=1153689476; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DEKS6OTHN/UpTjOxfSf0GHsnvOQo=3D; b=o31lqFD+AOYPMysIlPUpm4k5zcPgc6xEzenx6mbL5bTWoIOTYvxHYfCv7Q9sXikNW+DPbZOK rPMp1V+Whrt3oOD19ce9Q5VKpQhu9mabb/emntcmlljf/sZC00DUkaSt; Authentication-Results: sj-dkim-4.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > > Randall Stewart wrote: > >>Note to Joe, the older revision of anti-spoof comes right >>from the xml database... not sure why it did not snarf >>your latest version.. > > > I don't use XML, so maybe they incorporate xml2rfc-based stuff more > quickly? > > If not, it's _very_ out of date ;-) > > Joe > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm We will look into it and fix whatever is wrong.. xml can be funny at times.. and we could have some invalid tag.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 13 17:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18n0-00010N-EX; Thu, 13 Jul 2006 17:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18mz-00010D-5S for tcpm@ietf.org; Thu, 13 Jul 2006 17:32:05 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18mx-0001LM-Ov for tcpm@ietf.org; Thu, 13 Jul 2006 17:32:05 -0400 Received: from [128.9.176.35] (c1-vpn5.isi.edu [128.9.176.35]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DLUkH26898; Thu, 13 Jul 2006 14:30:47 -0700 (PDT) Message-ID: <44B6BB7F.7000602@isi.edu> Date: Thu, 13 Jul 2006 14:30:39 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Randall Stewart Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> <44B68831.5000307@isi.edu> <44B68A3C.5000506@cisco.com> <44B68BB1.90402@isi.edu> <44B6B886.3000409@cisco.com> In-Reply-To: <44B6B886.3000409@cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0034067944==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0034067944== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62C46B83C1668E3F643A18CD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62C46B83C1668E3F643A18CD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The tag probably refers to the individual submission, and should be updated to refer to the WG one. That's probably the disconnect ;-) Joe Randall Stewart wrote: > Joe Touch wrote: >> >> Randall Stewart wrote: >> >>> Note to Joe, the older revision of anti-spoof comes right >>> from the xml database... not sure why it did not snarf >>> your latest version.. >> >> >> I don't use XML, so maybe they incorporate xml2rfc-based stuff more >> quickly? >> >> If not, it's _very_ out of date ;-) >> >> Joe >> >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm > We will look into it and fix whatever is wrong.. xml can > be funny at times.. and we could have some invalid tag.. >=20 > R >=20 --------------enig62C46B83C1668E3F643A18CD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtrt/E5f5cImnZrsRAiBpAKD4Cujf+fh1P5wF2hOmkT7bR9dMiQCg7T5l /5+E4t2ClahjE77Q9GMMwJk= =dK6v -----END PGP SIGNATURE----- --------------enig62C46B83C1668E3F643A18CD-- --===============0034067944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0034067944==-- From tcpm-bounces@ietf.org Thu Jul 13 22:24:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1DLl-0004yl-Az; Thu, 13 Jul 2006 22:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1DLk-0004yZ-IQ for tcpm@ietf.org; Thu, 13 Jul 2006 22:24:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15Fw-00018N-OU for tcpm@ietf.org; Thu, 13 Jul 2006 13:45:44 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G158j-0003D8-1x for tcpm@ietf.org; Thu, 13 Jul 2006 13:38:18 -0400 Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DHaHH24381; Thu, 13 Jul 2006 10:36:17 -0700 (PDT) Message-ID: <44B6848B.5050108@isi.edu> Date: Thu, 13 Jul 2006 10:36:11 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.6 (--) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [tcpm] previous notes on tcp-secure-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2070166575==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2070166575== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig623350BAEAFE088BCBA097C2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig623350BAEAFE088BCBA097C2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here are my previous notes on v04, with comments to clarify. I do not feel that some were addressed in v05. I appreciate Randall's addressing them in the WG today, but it would have been useful to have addressed them on-list when 05 was issued. That would have saved substantial effort in re-reviewing 05 on points that were not addressed. I further felt that 05 was a cosmetic update to 04, especially given the detail provided below. FWIW, these were sent privately to Randall and the chairs in March; this is the first time they appear on this list. I have added "NOTE:" comments to clarify below. Joe ----------------------------------------------------------------------- A. the doc describes 3 different mods 1. RST 2. SYN 3. data injection It'd be useful to explain what the common thread is, and why all three are needed. RST and SYN fall into the same "short run for a long slide" category. NOTE: there are a set of solutions that are all presented in this document as related, and all implied as "quick fixes with large benefit" (short run/long slide). It'd be useful to explain them as having a common reason, rather than just as a shopping list of things to fix. The data injection stuff seems out of place, though. The solution is comparatively cumbersome and I don't believe as well agreed. It's also a bit misnamed (it's really a blind window sliding attack), and blind data injection is still fairly simple (in-window). B. the general document writing and presentation needs work including spelling, sentence structure, etc. NOTE: this refers to readability and comprehension of the issues and protocol changes required, to the extent that the current language gets in the way of that. C. I would suggest a more focused discussion as follows: a. section 1 should summarize tcp-antispoof in a paragraph or two, but otherwise ref off to that instead, it should focus on a few things: 1. how a TCP solution is different 2. why the group of mods to TCP are all related 3. why modifying TCP here is a good thing I would agree that cleaning up unintended holes in TCP processing is reasonable, esp. given the small mods that can accomplish them (e.g., for RST and SYN). I would prefer if that were the focus of the doc (safety from incorrect messages, regardless of intent) , with the side effect of increasing resistance to some recent attacks, BUT that if real protection is required, that real security is recommended (e.g., IPsec). Where increased resistance is described ("much harder"), it should be quantified. b. the protocol sections should discuss things 793-style Some of the discussion of the changes seems more like a recipe than a protocol spec change. Specific portions of 793 should be quoted where needed, and changes clearly indicated. These should be entitled "Changes to 793" or somesuch, rather than 'Mitigation'. c. section 5- the blind data stuff, is "too long a walk for a short slide" It requires new TCB state (MAX.SND.WND) which is very informally introduced, and not discussed: - do you save the window scale for that max? - does this present an opportunity for attack itself? While this protects from some ACK attacks, it's still sufficiently easy, after this mod, to inject ACKs that accomplish the same purpose, or to inject data similarly. I would recommend removing it. D. ACK throttling needs a more clear discussion The requirements need to be separated and condensed as a list, rather than dispersed througout (the same recommendation applies to other sections, BTW). The potential for implementation deadlock deserves much more than a passing reference; this is a substantial concern. If there's a way around it, it should be discussed. It seems incumbent to me that this solution MUST ;-) specify the protocol behavior in such a way that such deadlocks are not possible. (793 does this all over the place, by placing rules on the order of handling queued segments, order of handling signals, data, etc., etc.) E. the backward compatibility section needs to highlight a few more thing= s: - - when incrementally or mutually deployed (separate discussions): - which sides benefit and how - which sides are impacted and how - is there any impact or benefit to third parties middlebox considerations are a subsection of backward compatibility, IMO I would suggest that mboxes that modify TCP packets are briefly described as "deserving what they get" rather than going into details. What some mboxes do is irrelevant; more to the point is what we can expect a mbox to do, and that's not really static anyway (unless you refer off to the RFC defining the versions, like half-cone, full-cone, etc.) Finally, I would suggest that protection from mbox interference is better provided by IPsec (which would interfere with mbox mod of the packets). ;-) Interoperability reports seem like at best an appendix, but more like something that would accompany the submission of this doc as standards-track. It doesn't seem like it ought to be inside the doc. F. security considerations should address the benefits vs limits in specific - how much more security is provided, and what are the limits. it should also note that on-path attacks are still possible, and that data injection attacks are still possible. it should finally note that full protection warrants the use of IPsec (that's what security consids are for!) if there are still deadlocks possible that can be triggered by malicious parties, then that needs to be noted here too G. section 12 ought to note the input of the TCPM WG, and a few names there if you feel appropriate. This work was, IMO, polished by the WG a bit since I first saw it (e.g., the need for ACK throttling), and that too should (IMO) be noted. NOTE: i.e., the ack throttling (ACK war avoidance solution) should be noted as a WG contribution. --- --------------enig623350BAEAFE088BCBA097C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtoSLE5f5cImnZrsRAqIjAJwI7ZGVWcfjAeWwfJCpWgBfg3fC7ACfdF1t IAG9w8X609CuJxBMKfrBhUQ= =Hr/6 -----END PGP SIGNATURE----- --------------enig623350BAEAFE088BCBA097C2-- --===============2070166575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2070166575==-- From tcpm-bounces@ietf.org Fri Jul 14 05:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1KQv-0004oC-7B; Fri, 14 Jul 2006 05:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1KQt-0004o7-Vw for tcpm@ietf.org; Fri, 14 Jul 2006 05:58:04 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1KQs-0001yu-C5 for tcpm@ietf.org; Fri, 14 Jul 2006 05:58:03 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6E9vhuk019381; Fri, 14 Jul 2006 06:57:45 -0300 Message-Id: <7.0.1.0.0.20060714061250.08589008@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 14 Jul 2006 06:51:54 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Ted Faber , Mark Allman Subject: [tcpm] Question about the path of tcpsecure and ICMP attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, Recent discussion on the tcpsecure draft has made me think (again) about the path of the tcpsecure and the ICMP attacks draft. tcpsecure is meant for standards track, while the ICMP attacks draft is meant for Informational. tcpsecure aims to address, among others, blind connection-reset attacks, which require an attacker to spoof a segment that contains the four-tuple that identifies the connection *only* is "in window". Source IP address spoofing is necessary. icmp-attacks aims to address, among others, blind connection-reset attacks, which *only* requires the attacker to spoof a packet that contains the four-tuple that identifies the connection to be attacked. Source IP address spoofing is not necessary. As Joe pointed out, it's clear that if you bother to mitigate (TCP-based) in-window attacks, you will first (or "also", if you want) mitigate the ICMP-based ones, for which the TCP sequence number does not matter at all. However, with the current path that each document has, the specifications would end up fixed for the "in window" (TCP-based) attacks, but not for the more simple ICMP-based counterpart. A number of folks have mentioned that they would like the specs fixed wrt the ICMP attacks. But the path of the ICMP attacks draft is still Informational (as decided in IETF 64). I'll be working on the next revision of the ICMP attacks anytime soon. Among all the feedback there is to address, there's that of rephrasing the text that was originally in RFC2119-speak (as the draft is currently meant for Informational). Therefore, it would be useful to make that of which path the ICMP attacks draft aims to, so that I don't go back and forth with the text that makes the draft prescriptive. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jul 15 17:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1rKW-0004lG-Ey; Sat, 15 Jul 2006 17:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1rKV-0004d3-Hb for tcpm@ietf.org; Sat, 15 Jul 2006 17:05:39 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1rKT-0001ZK-T6 for tcpm@ietf.org; Sat, 15 Jul 2006 17:05:39 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6FL5XJx022661; Sat, 15 Jul 2006 18:05:36 -0300 Message-Id: <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 15 Jul 2006 16:27:00 -0300 To: Joe Touch , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 In-Reply-To: <44B682AB.9010702@isi.edu> References: <44B682AB.9010702@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 14:28 13/07/2006, Joe Touch wrote: >The doc should also indicate that preventing these attacks does NOT >prevent ICMP attacks (and cite Gont's draft in this regard); it would be >useful for the security considerations to address whether ICMPs should >be blocked altogether and what the impact of that would be. Without such >blocking, it's not clear what the utility of this solution would be. I disagree with having the security considerations section of a document that does not focus on ICMP to basically propose to eliminate ICMP. There's an entire document of this very same WG dicussing the relationship between ICMP and TCP. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jul 15 17:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1rKW-0004nt-QG; Sat, 15 Jul 2006 17:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1rKV-0004d5-Hf for tcpm@ietf.org; Sat, 15 Jul 2006 17:05:39 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1rKT-0001ZJ-T6 for tcpm@ietf.org; Sat, 15 Jul 2006 17:05:39 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6FL5XJr022661; Sat, 15 Jul 2006 18:05:34 -0300 Message-Id: <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 15 Jul 2006 15:42:45 -0300 To: "Anantha Ramaiah \(ananth\)" , "Joe Touch" , From: Fernando Gont Subject: RE: [tcpm] feedcback on tcp-secure-05 In-Reply-To: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer. cisco.com> References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:04 13/07/2006, Anantha Ramaiah \(ananth\) wrote: > > The doc should also indicate that preventing these attacks > > does NOT prevent ICMP attacks (and cite Gont's draft in this > > regard); it would be useful for the security considerations > > to address whether ICMPs should be blocked altogether and > > what the impact of that would be. Without such blocking, it's > > not clear what the utility of this solution would be. > >Ok. I don't think tcpsecure should make any advice on what to do with ICMP. Just make it clear that the introduced mechanisms do not prevent ICMP-based attacks against TCP, and provide a pointer to draft-ietf-tcpm-icmp-attacks-00.txt . If you are going to make any other statement on this issue, state that the ICMP-based attacks are easier to perform, and thus should be mitigated (if not, it's ICMP that is the "weakest link in the chain"). You could also add that, fortunately, virtually every implementation has mitigated the ICMP attacks described in draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not all) the counter-measures described in that draft. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jul 15 18:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1t6r-0007PF-Ac; Sat, 15 Jul 2006 18:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1t6p-0007JL-Ul for tcpm@ietf.org; Sat, 15 Jul 2006 18:59:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1t6o-0002pt-KA for tcpm@ietf.org; Sat, 15 Jul 2006 18:59:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2006 15:59:38 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6FMxbBR018541; Sat, 15 Jul 2006 15:59:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6FMxbJi018713; Sat, 15 Jul 2006 15:59:37 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Jul 2006 15:59:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05 Date: Sat, 15 Jul 2006 15:59:36 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801D95F1A@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05 Thread-Index: AcaoUmo0Txay4YXTSvK2OMo/ADSDlwACpFMQ From: "Anantha Ramaiah \(ananth\)" To: "Fernando Gont" , "Joe Touch" , X-OriginalArrivalTime: 15 Jul 2006 22:59:37.0587 (UTC) FILETIME=[58BFE430:01C6A862] DKIM-Signature: a=rsa-sha1; q=dns; l=2246; t=1153004377; x=1153868377; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DCeksYhPTKiajql2H6p2yZiTQwso=3D; b=I1vvNbe8vVgA3GJuY22MTWdsX5g3fjOwqsDsLJStOBNI6NphtT89ypus3Uf4UtT4FrzSW83S aWgrV4mzz+lqrlQUc1vdnDsB0jDnS4cpjUzoV/cGOZXjuiupHDwawgPt; Authentication-Results: sj-dkim-3.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando,=20 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Saturday, July 15, 2006 11:43 AM > To: Anantha Ramaiah (ananth); Joe Touch; tcpm@ietf.org > Subject: RE: [tcpm] feedcback on tcp-secure-05 >=20 > At 15:04 13/07/2006, Anantha Ramaiah \(ananth\) wrote: >=20 > > > The doc should also indicate that preventing these=20 > attacks does NOT=20 > > > prevent ICMP attacks (and cite Gont's draft in this regard); it=20 > > > would be useful for the security considerations to=20 > address whether=20 > > > ICMPs should be blocked altogether and what the impact of=20 > that would=20 > > > be. Without such blocking, it's not clear what the=20 > utility of this=20 > > > solution would be. > > > >Ok. >=20 > I don't think tcpsecure should make any advice on what to do=20 > with ICMP. >=20 > Just make it clear that the introduced mechanisms do not=20 > prevent ICMP-based attacks against TCP, and provide a pointer=20 > to draft-ietf-tcpm-icmp-attacks-00.txt . I agree..=20 May be we should just say something like : "The mitigations discussed in this document does not prevent ICMP attacks" and provide a citation to your document. One of the reasons why it was felt that the above isn't necessary is because : tcpsecure refers Joe's antispoof which in turn refers your document.=20 >=20 > If you are going to make any other statement on this issue,=20 > state that the ICMP-based attacks are easier to perform, and=20 > thus should be mitigated (if not, it's ICMP that is the=20 > "weakest link in the chain"). >=20 > You could also add that, fortunately, virtually every=20 > implementation has mitigated the ICMP attacks described in=20 > draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not > all) the counter-measures described in that draft. We really don't want to cause a bloat to the security considerations section. Also the scope the document is limited and it is better to stick to that.=20 =20 -Anantha >=20 > Kindest regards, >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP=20 > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 17 00:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2LAf-00079L-BN; Mon, 17 Jul 2006 00:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2LAd-00079F-Cg for tcpm@ietf.org; Mon, 17 Jul 2006 00:57:27 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2LAc-00089d-1D for tcpm@ietf.org; Mon, 17 Jul 2006 00:57:27 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6H4ufH15175; Sun, 16 Jul 2006 21:56:41 -0700 (PDT) Message-ID: <44BB1882.6030904@isi.edu> Date: Sun, 16 Jul 2006 21:56:34 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0494870908==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0494870908== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29DA37FF784C066CEB09D23B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29DA37FF784C066CEB09D23B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 15:04 13/07/2006, Anantha Ramaiah \(ananth\) wrote: >=20 >> > The doc should also indicate that preventing these attacks >> > does NOT prevent ICMP attacks (and cite Gont's draft in this >> > regard); it would be useful for the security considerations >> > to address whether ICMPs should be blocked altogether and >> > what the impact of that would be. Without such blocking, it's >> > not clear what the utility of this solution would be. >> >> Ok. >=20 > I don't think tcpsecure should make any advice on what to do with ICMP.= >=20 > Just make it clear that the introduced mechanisms do not prevent > ICMP-based attacks against TCP, and provide a pointer to > draft-ietf-tcpm-icmp-attacks-00.txt . >=20 > If you are going to make any other statement on this issue, state that > the ICMP-based attacks are easier to perform, and thus should be > mitigated (if not, it's ICMP that is the "weakest link in the chain"). >=20 > You could also add that, fortunately, virtually every implementation ha= s > mitigated the ICMP attacks described in > draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not all) > the counter-measures described in that draft. That last point doesn't obviate the issue that ICMP packets - even validated by the mitigations in the draft above - are still easier to spoof and can be spoofed by third parties than any of the attacks in tcp-secure. I.e., they remain the weakest link, and worrying about tcp-secure protections is nonsensical by comparison, UNLESS ICMPs are entirely blocked. Joe --------------enig29DA37FF784C066CEB09D23B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuxiCE5f5cImnZrsRAjRGAKCNCOqXJljD5vRphnHrBX6n8AQgfACePCOh aLkjLFp/6B08yUaKHv2V4sg= =uDs2 -----END PGP SIGNATURE----- --------------enig29DA37FF784C066CEB09D23B-- --===============0494870908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0494870908==-- From tcpm-bounces@ietf.org Mon Jul 17 01:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2LET-0007ry-97; Mon, 17 Jul 2006 01:01:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2LES-0007rt-R9 for tcpm@ietf.org; Mon, 17 Jul 2006 01:01:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2LER-0000EY-EL for tcpm@ietf.org; Mon, 17 Jul 2006 01:01:24 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6H50SH15837; Sun, 16 Jul 2006 22:00:29 -0700 (PDT) Message-ID: <44BB1965.9070305@isi.edu> Date: Sun, 16 Jul 2006 22:00:21 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1055655331==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1055655331== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44854899461229A16A2C80E5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44854899461229A16A2C80E5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 14:28 13/07/2006, Joe Touch wrote: >=20 >> The doc should also indicate that preventing these attacks does NOT >> prevent ICMP attacks (and cite Gont's draft in this regard); it would = be >> useful for the security considerations to address whether ICMPs should= >> be blocked altogether and what the impact of that would be. Without su= ch >> blocking, it's not clear what the utility of this solution would be. >=20 > I disagree with having the security considerations section of a documen= t > that does not focus on ICMP to basically propose to eliminate ICMP. >=20 > There's an entire document of this very same WG dicussing the > relationship between ICMP and TCP. The ICMP document is a general document; this document (IMO) is more about what to do when under suspected attack (or should be, to some exten= t). If tcp-secure doesn't recommend blocking when tcp-secure is active (i.e., when such attacks are suspected), then there is no point to the rest of tcp-secure. It is useless to address the more challenging spoofing attack vector and not address the easier one. Joe --------------enig44854899461229A16A2C80E5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuxllE5f5cImnZrsRArUuAJ9PoOh2d2T1FJR6Djkn1Dv8eoHMbQCfbYL/ EKW0NBBSYAUlOjPSJQ6ihuw= =V2b8 -----END PGP SIGNATURE----- --------------enig44854899461229A16A2C80E5-- --===============1055655331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1055655331==-- From tcpm-bounces@ietf.org Mon Jul 17 03:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2NDa-00076T-UI; Mon, 17 Jul 2006 03:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2NDY-00076O-Sf for tcpm@ietf.org; Mon, 17 Jul 2006 03:08:36 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2NDX-0003TZ-H8 for tcpm@ietf.org; Mon, 17 Jul 2006 03:08:36 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2006 00:08:35 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6H78Ycm014186; Mon, 17 Jul 2006 00:08:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6H78Y2D023991; Mon, 17 Jul 2006 00:08:34 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Jul 2006 00:08:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05 Date: Mon, 17 Jul 2006 00:08:32 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801D95FC7@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05 Thread-Index: AcapXYpPcCTJCmWoQ5iftiNRLCMTCAAB8VMw From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 17 Jul 2006 07:08:34.0299 (UTC) FILETIME=[D134A4B0:01C6A96F] DKIM-Signature: a=rsa-sha1; q=dns; l=3424; t=1153120114; x=1153984114; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DCeksYhPTKiajql2H6p2yZiTQwso=3D; b=LGi5OILqjKYsUGJeirEt9LpMHzw4Z+y2WywQuf/J2GwfqZyn7rZQkZzUCEf5QsW+Rt2ncfYN umYUi8oRqRWiSo6xVZiPrZfmiG741clbkRvmWcUQitr5sWRc6isuzddU; Authentication-Results: sj-dkim-1.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > >> > would be. Without such blocking, it's not clear what the=20 > utility of=20 > >> > this solution would be. > >> > >> Ok. > >=20 > > I don't think tcpsecure should make any advice on what to=20 > do with ICMP. > >=20 > > Just make it clear that the introduced mechanisms do not prevent=20 > > ICMP-based attacks against TCP, and provide a pointer to=20 > > draft-ietf-tcpm-icmp-attacks-00.txt . > >=20 > > If you are going to make any other statement on this issue,=20 > state that=20 > > the ICMP-based attacks are easier to perform, and thus should be=20 > > mitigated (if not, it's ICMP that is the "weakest link in=20 > the chain"). > >=20 > > You could also add that, fortunately, virtually every=20 > implementation=20 > > has mitigated the ICMP attacks described in=20 > > draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most=20 > (if not all)=20 > > the counter-measures described in that draft. >=20 > That last point doesn't obviate the issue that ICMP packets -=20 > even validated by the mitigations in the draft above - are=20 > still easier to spoof and can be spoofed by third parties=20 > than any of the attacks in tcp-secure. >=20 > I.e., they remain the weakest link, and worrying about=20 > tcp-secure protections is nonsensical by comparison, UNLESS=20 > ICMPs are entirely blocked. Actually I have to dis-agree to this. The tcp-secure is by no means an exhaustive list of attacks that can be performed on TCP layer. It's main focus is on providing robustness to some of the blind in-window attacks. Now we have a separate document which talks about the ICMP based attacks (draft-ietf-tcpm-icmp-attacks-xx.txt) and it's mitigation, so it would be better to just provide a reference to the same in tcp-secure and leave it at that. To make recommendations on to blocking ICMP is outside the scope of tcp-secure. Another point to note is that TCP SHOULD act (not a MUST) on ICMP reported hard errors. Also in some cases like "port unreachable" can be ignored since TCP uses the RST for the purpose of port unreachability. This is as per RFC 1122.=20 - Some applications would chose to ignore the so called hard errors for a TCP connection. In other words the behaviour can be controlled by a CLI and the default would be to ignore this hard errors. So the connection reset wouldn't happen. - Some firewalls deliberately block ICMP messages rendering the attack useless. I guess my point is ICMP attacks may be a weakest link, but wouldn't cause connection resets with proper installed workarounds in place. Yes, I mean without voilating the current RFC's. Also with or without ICMP mitigations in place, one could still cause a TCP connection to RESET, if the mitigations described in tcp-secure isn't present. So the tcp-secure suggestions are useful with or without ICMP blocking/unblocking. But is it foolproof ? It isn't. Using MD5 makes the connection reset even harder, other tougher MAC's even harder. So all I am trying to derive is that, I agree with Fernando about tcp-secure shouldn't be making any recommendations on whether to block or unblock ICMP messages. I think these drafts are orthogonal to each other. But it would be ok to mention about the ICMP attacks in the security considerations of tcp-secure and provide a pointer to the same. -Anantha >=20 > Joe >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 17 10:31:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2U8M-0004RI-1x; Mon, 17 Jul 2006 10:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2U8K-0004RD-Rv for tcpm@ietf.org; Mon, 17 Jul 2006 10:31:40 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2U8J-00023I-GN for tcpm@ietf.org; Mon, 17 Jul 2006 10:31:40 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6HEUqH14866; Mon, 17 Jul 2006 07:30:52 -0700 (PDT) Message-ID: <44BB9F16.80106@isi.edu> Date: Mon, 17 Jul 2006 07:30:46 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <0C53DCFB700D144284A584F54711EC5801D95FC7@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801D95FC7@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0520751935==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0520751935== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFBC872E9302CE546FC8B143" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFBC872E9302CE546FC8B143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E. > Another point to note is that TCP SHOULD act (not a MUST) on ICMP > reported hard errors. Also in some cases like "port unreachable" can be= > ignored since TCP uses the RST for the purpose of port unreachability. > This is as per RFC 1122.=20 1122 actually states exactly the opposite: A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. > - Some applications would chose to ignore the so called hard errors for= > a TCP connection. In other words the behaviour can be controlled by a > CLI and the default would be to ignore this hard errors. So the > connection reset wouldn't happen. The default SHOULD be to act on hard errors unless overridden by the application; to do otherwise would be to redefine 1122 in this regard. =2E.. > I guess my point is ICMP attacks may be a weakest link, but wouldn't > cause connection resets with proper installed workarounds in place. Yes= , > I mean without voilating the current RFC's. Those workarounds MUST be in place, or they ARE the weakest link. That's the point that this document must discuss at least. > Also with or without ICMP mitigations in place, one could still cause a= > TCP connection to RESET, if the mitigations described in tcp-secure > isn't present. Without ICMP protection, why bother with a RST when the ICMP is _easier_ to generate? Joe --------------enigDFBC872E9302CE546FC8B143 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEu58WE5f5cImnZrsRAvhZAJ9We/UG4XevOJrtyxiQaOW0lK90xgCeJeS0 o8ncUIOHKZ6fvNO3gcsVAII= =ukxL -----END PGP SIGNATURE----- --------------enigDFBC872E9302CE546FC8B143-- --===============0520751935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0520751935==-- From tcpm-bounces@ietf.org Mon Jul 17 14:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XRD-0003Je-Lm; Mon, 17 Jul 2006 14:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XRB-0003JL-BH for tcpm@ietf.org; Mon, 17 Jul 2006 14:03:21 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2XR9-0004Z8-VG for tcpm@ietf.org; Mon, 17 Jul 2006 14:03:21 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6HI2cu21461; Mon, 17 Jul 2006 11:02:38 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k6HI2cne022731; Mon, 17 Jul 2006 11:02:38 -0700 (PDT) (envelope-from faber) Date: Mon, 17 Jul 2006 11:02:38 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] feedcback on tcp-secure-05 Message-ID: <20060717180238.GE38453@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> Mime-Version: 1.0 In-Reply-To: <44BB1965.9070305@isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422974646==" Errors-To: tcpm-bounces@ietf.org --===============0422974646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PPYy/fEw/8QCHSq3" Content-Disposition: inline --PPYy/fEw/8QCHSq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As a participant, not a chair. On Sun, Jul 16, 2006 at 10:00:21PM -0700, Joe Touch wrote: > The ICMP document is a general document; this document [tcpsecure > --tvf] (IMO) is more about what to do when under suspected attack (or > should be, to some extent). That's more broad a view of tcpsecure than the one I have. It's a mitigation of a specific attack vector, not a handbook for dealing with off-path TCP attacks. Personally I prefer to keep it more tightly scoped so there's a chance of finishing it. > If tcp-secure doesn't recommend blocking when tcp-secure is active > (i.e., when such attacks are suspected), then there is no point to the > rest of tcp-secure. It is useless to address the more challenging > spoofing attack vector and not address the easier one. While I'm not opposed to adding text to that effect, I don't think it's a requirement. There are plenty of other possibilities for attack when the tcpsecure code additions are exercised, and I don't see that this document needs to address them all. For that matter, the tcpsecure document has never proposed a detection mechanism for those attacks. All that is new work, and IMHO, well beyond the scope of the document that the WG agreed to. I'm happy to be convinced otherwise. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --PPYy/fEw/8QCHSq3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEu9C+aUz3f+Zf+XsRAuXpAJ9yfEuRgfPkO/2Nc16voN6KPPsQTgCeMUNe 7f6ypYL+t2G5Vz2kLj8Gv0A= =ycpt -----END PGP SIGNATURE----- --PPYy/fEw/8QCHSq3-- --===============0422974646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0422974646==-- From tcpm-bounces@ietf.org Mon Jul 17 22:34:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2fPq-00035b-9W; Mon, 17 Jul 2006 22:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2fPo-00033K-5B for tcpm@ietf.org; Mon, 17 Jul 2006 22:34:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2fOJ-0007ww-73 for tcpm@ietf.org; Mon, 17 Jul 2006 22:32:56 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2006 19:32:55 -0700 X-IronPort-AV: i="4.06,253,1149490800"; d="scan'208"; a="329604396:sNHT28665994" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6I2WsH4001386; Mon, 17 Jul 2006 19:32:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6I2WrJi006992; Mon, 17 Jul 2006 19:32:53 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 19:32:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05 Date: Mon, 17 Jul 2006 19:32:52 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801DF8827@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05 Thread-Index: AcaprbZOVXuVb08gR4qFs6D1JlymzQAYC+VQ From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 18 Jul 2006 02:32:53.0725 (UTC) FILETIME=[78AB18D0:01C6AA12] DKIM-Signature: a=rsa-sha1; q=dns; l=4338; t=1153189974; x=1154053974; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DCeksYhPTKiajql2H6p2yZiTQwso=3D; b=ekJ0O1t7kZMGYIKffrvL07f/X4/G7veE4HDe7F3s251uGeCBAEBD5huOazDxiRrFRMJHgeBV 91iHHf4e+z3q+FfiN3/J3EWQUN+m03G8LEzBzRimA8Q4dhCn/2PUBRe5; Authentication-Results: sj-dkim-1.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Monday, July 17, 2006 7:31 AM > To: Anantha Ramaiah (ananth) > Cc: Fernando Gont; tcpm@ietf.org > Subject: Re: [tcpm] feedcback on tcp-secure-05 >=20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > .. > > Another point to note is that TCP SHOULD act (not a MUST) on ICMP=20 > > reported hard errors. Also in some cases like "port=20 > unreachable" can=20 > > be ignored since TCP uses the RST for the purpose of port=20 > unreachability. > > This is as per RFC 1122.=20 >=20 > 1122 actually states exactly the opposite: >=20 > A transport protocol > that has its own mechanism for notifying the sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose. Yep, I stand corrected but one of main points above was to point out the SHOULD language (which makes sense) instead of MUST. >=20 > > - Some applications would chose to ignore the so called hard errors=20 > > for a TCP connection. In other words the behaviour can be=20 > controlled=20 > > by a CLI and the default would be to ignore this hard=20 > errors. So the=20 > > connection reset wouldn't happen. >=20 > The default SHOULD be to act on hard errors unless overridden=20 > by the application; to do otherwise would be to redefine 1122=20 > in this regard. Going neutral here, since the systems which I have worked do ignore them by default and it isn't an RFC voilation. As per RFC 2119 : "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Most of the applications would like to have a say in the treatment of ICMP errors by requesting the errors to be passed to it and then determine the course of action to take. For the ICMP hard errors described, the action generally doesn't result in connection closure and also some applications don't even register for some of the hard errors and also expect TCP not to close the connection instead silently ignore them Actually application or TCP level keepalives or retransmission timeouts act as a catalyst for the connection closure generally and not ICMP errors. But YMMV and I do not intend to argue on this point. Just stating my experience. >=20 > ... > > I guess my point is ICMP attacks may be a weakest link, but=20 > wouldn't=20 > > cause connection resets with proper installed workarounds in place.=20 > > Yes, I mean without voilating the current RFC's. >=20 > Those workarounds MUST be in place, or they ARE the weakest=20 > link. That's the point that this document must discuss at least. I don't think that tcpsecure document should discuss these workarounds or advise anything of that sort. It is always good to keep the scope of the document right and tight. >=20 > > Also with or without ICMP mitigations in place, one could=20 > still cause=20 > > a TCP connection to RESET, if the mitigations described in=20 > tcp-secure=20 > > isn't present. >=20 > Without ICMP protection, why bother with a RST when the ICMP=20 > is _easier_ to generate? Easier to generate but workarounds can be planted if necessary like I have described in earlier emails. On the other hand there aren't any known "generic workarounds" available for the issues described in tcp-secure. I say generic workarounds since MD5 is used only by a handful of applications like BGP, LDP and is a costly workaround and=20 Anyways just to summarize : The tcp-secure document, can, at the most state something informative like "ICMP attacks aren't covered in this document blah blah..." and provide a pointer to the icmp draft if needed. To suggest about blocking ICMP etc., calls for stretching too far the scope of the doc and also it introduces obvious incompleteness. What if somebody wants to provide some pointer and suggest some blocking/mitigation mechanisms for something else..? I see no end to this that way.. Agree/dis-agree ? :) -Anantha >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 17 22:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2fQ1-0003RP-86; Mon, 17 Jul 2006 22:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2fQ0-0003M6-1K for tcpm@ietf.org; Mon, 17 Jul 2006 22:34:40 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2fJC-0007p6-Lg for tcpm@ietf.org; Mon, 17 Jul 2006 22:27:40 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6I2RYjm013230; Mon, 17 Jul 2006 23:27:35 -0300 Message-Id: <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 17 Jul 2006 05:33:01 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 In-Reply-To: <44BB1882.6030904@isi.edu> References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 01:56 17/07/2006, Joe Touch wrote: > > You could also add that, fortunately, virtually every implementation has > > mitigated the ICMP attacks described in > > draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not all) > > the counter-measures described in that draft. > >That last point doesn't obviate the issue that ICMP packets - even >validated by the mitigations in the draft above - are still easier to >spoof and can be spoofed by third parties than any of the attacks in >tcp-secure. The counter-measures in the ICMP attacks draft eliminate the ICMP-based connection reset, eliminate the Source Quench attack, and require the attacker to be a Man In the Middle (*) for him to successfully perform an attack against the PMTUD mechanism. (*) Even if he was able to sniff the traffic that corresponds to the connection, his attack (*) wouldn't succeed - He should be able to selectively drop packets that correspond to the attacked connection. It is clear that with the ICMP counter-measures in place, TCP-based attacks are "the weakest link in the change". You don't need to "drop them all". Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 00:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2gnf-0007XX-Hm; Tue, 18 Jul 2006 00:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2gnd-0007VE-Qb for tcpm@ietf.org; Tue, 18 Jul 2006 00:03:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2gnc-0000VW-GJ for tcpm@ietf.org; Tue, 18 Jul 2006 00:03:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2006 21:03:08 -0700 X-IronPort-AV: i="4.06,253,1149490800"; d="scan'208"; a="306363999:sNHT36118584" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6I437rc014430; Mon, 17 Jul 2006 21:03:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6I4372D007327; Mon, 17 Jul 2006 21:03:07 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 21:03:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05 Date: Mon, 17 Jul 2006 21:03:04 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D0216A2B0@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05 Thread-Index: Acapy1XHaAnm8fV9Sk2/ftmUqLrHuQAU7LfQ From: "Mitesh Dalal \(mdalal\)" To: "Ted Faber" , "Joe Touch" X-OriginalArrivalTime: 18 Jul 2006 04:03:07.0491 (UTC) FILETIME=[13863B30:01C6AA1F] DKIM-Signature: a=rsa-sha1; q=dns; l=1705; t=1153195387; x=1154059387; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=22Mitesh=20Dalal=20\(mdalal\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DmeRheTbS9RSYJDymsDxRjbYxCUM=3D; b=fDyml6MpGmBLT2TFmsgOCgMpRFdibluwd9meNfp0p2VGASMIIUot2IMtFrHQxGwMbp1OCODm 6363Jy75bJaF5mXKT9H31DTByzzdXCjHbijVfNGw/yKXNZR/nW0eD0z0; Authentication-Results: sj-dkim-4.cisco.com; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I second Ted's opinion. =20 -----Original Message----- From: Ted Faber [mailto:faber@ISI.EDU]=20 Sent: Monday, July 17, 2006 11:03 AM To: Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] feedcback on tcp-secure-05 As a participant, not a chair. On Sun, Jul 16, 2006 at 10:00:21PM -0700, Joe Touch wrote: > The ICMP document is a general document; this document [tcpsecure=20 > --tvf] (IMO) is more about what to do when under suspected attack (or > should be, to some extent). That's more broad a view of tcpsecure than the one I have. It's a mitigation of a specific attack vector, not a handbook for dealing with off-path TCP attacks. Personally I prefer to keep it more tightly scoped so there's a chance of finishing it. > If tcp-secure doesn't recommend blocking when tcp-secure is active=20 > (i.e., when such attacks are suspected), then there is no point to the > rest of tcp-secure. It is useless to address the more challenging=20 > spoofing attack vector and not address the easier one. While I'm not opposed to adding text to that effect, I don't think it's a requirement. There are plenty of other possibilities for attack when the tcpsecure code additions are exercised, and I don't see that this document needs to address them all. For that matter, the tcpsecure document has never proposed a detection mechanism for those attacks. All that is new work, and IMHO, well beyond the scope of the document that the WG agreed to. I'm happy to be convinced otherwise. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 09:34:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pi5-0005iW-0l; Tue, 18 Jul 2006 09:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pi3-0005iR-AA for tcpm@ietf.org; Tue, 18 Jul 2006 09:33:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pi1-000183-Ri for tcpm@ietf.org; Tue, 18 Jul 2006 09:33:59 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6IDXOH08095; Tue, 18 Jul 2006 06:33:24 -0700 (PDT) Message-ID: <44BCE318.9060104@isi.edu> Date: Tue, 18 Jul 2006 06:33:12 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <0C53DCFB700D144284A584F54711EC5801DF8827@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801DF8827@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0884714396==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0884714396== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2FFFE75505B65498DD8DF199" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2FFFE75505B65498DD8DF199 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU]=20 >> Sent: Monday, July 17, 2006 7:31 AM >> To: Anantha Ramaiah (ananth) >> Cc: Fernando Gont; tcpm@ietf.org >> Subject: Re: [tcpm] feedcback on tcp-secure-05 >> >> >> >> Anantha Ramaiah (ananth) wrote: >> .. >>> Another point to note is that TCP SHOULD act (not a MUST) on ICMP=20 >>> reported hard errors. Also in some cases like "port=20 >> unreachable" can=20 >>> be ignored since TCP uses the RST for the purpose of port=20 >> unreachability. >>> This is as per RFC 1122.=20 >> 1122 actually states exactly the opposite: >> >> A transport protocol >> that has its own mechanism for notifying the sender that a= >> port is unreachable (e.g., TCP, which sends RST segments) >> MUST nevertheless accept an ICMP Port Unreachable for the >> same purpose. >=20 > Yep, I stand corrected but one of main points above was to point out th= e > SHOULD language (which makes sense) instead of MUST. So you're changing 1122? That needs to be highlighted. >>> - Some applications would chose to ignore the so called hard errors=20 >>> for a TCP connection. In other words the behaviour can be=20 >> controlled=20 >>> by a CLI and the default would be to ignore this hard=20 >> errors. So the=20 >>> connection reset wouldn't happen. >> The default SHOULD be to act on hard errors unless overridden=20 >> by the application; to do otherwise would be to redefine 1122=20 >> in this regard. >=20 > Going neutral here, since the systems which I have worked do ignore the= m > by default and it isn't an RFC voilation. >=20 > As per RFC 2119 : >=20 > "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there= > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." >=20 > Most of the applications would like to have a say in the treatment of > ICMP errors by requesting the errors to be passed to it and then > determine the course of action to take. For the ICMP hard errors > described, the action generally doesn't result in connection closure an= d > also some applications don't even register for some of the hard errors > and also expect TCP not to close the connection instead silently ignore= > them 1122 fairly directly indicates that ICMP port unreachable MUST be handled exactly as a RST ("accept for the same purpose"). A SHOULD would be a change to that, and needs to be highlighted as a change to 1122. Further, as you note above, negating a should implies that the document indicate the "particular circumstances" that apply. The doc doesn't currently discuss interpreting violating messages as an attack and after a threshold is reached THEN negating the SHOULD. That's key. > Actually application or TCP level keepalives or retransmission timeouts= > act as a catalyst for the connection closure generally and not ICMP > errors. But YMMV and I do not intend to argue on this point. Just > stating my experience. >=20 >> ... >>> I guess my point is ICMP attacks may be a weakest link, but=20 >> wouldn't=20 >>> cause connection resets with proper installed workarounds in place.=20 >>> Yes, I mean without voilating the current RFC's. >> Those workarounds MUST be in place, or they ARE the weakest=20 >> link. That's the point that this document must discuss at least. >=20 > I don't think that tcpsecure document should discuss these workarounds > or advise anything of that sort. It is always good to keep the scope of= > the document right and tight. "right and tight" isn't a justification for not discussing the "particular circumstances" above. >>> Also with or without ICMP mitigations in place, one could=20 >> still cause=20 >>> a TCP connection to RESET, if the mitigations described in=20 >> tcp-secure=20 >>> isn't present. >> Without ICMP protection, why bother with a RST when the ICMP=20 >> is _easier_ to generate? >=20 > Easier to generate but workarounds can be planted if necessary like I > have described in earlier emails. On the other hand there aren't any > known "generic workarounds" available for the issues described in > tcp-secure. I say generic workarounds since MD5 is used only by a > handful of applications like BGP, LDP and is a costly workaround and=20 >=20 > Anyways just to summarize : >=20 > The tcp-secure document, can, at the most state something informative > like "ICMP attacks aren't covered in this document blah blah..." and > provide a pointer to the icmp draft if needed. >=20 > To suggest about blocking ICMP etc., calls for stretching too far the > scope of the doc and also it introduces obvious incompleteness.=20 I'm not going to debate this further. I'll be glad to note the omission to the Security AD; if they think this doc is useful without it, fine. > What if > somebody wants to provide some pointer and suggest some > blocking/mitigation mechanisms for something else..? I see no end to > this that way.. >=20 > Agree/dis-agree ? >=20 > :) > -Anantha >> Joe >> >> --------------enig2FFFE75505B65498DD8DF199 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvOMdE5f5cImnZrsRAhHCAJwOaRLb7Q6fKDMxd/cKtz82wKjovgCaAoZI 0hFhoIWpXy7US3Ox8goqRJw= =P2kd -----END PGP SIGNATURE----- --------------enig2FFFE75505B65498DD8DF199-- --===============0884714396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0884714396==-- From tcpm-bounces@ietf.org Tue Jul 18 09:42:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ppy-0002gm-7U; Tue, 18 Jul 2006 09:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ppw-0002dE-8r for tcpm@ietf.org; Tue, 18 Jul 2006 09:42:08 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ppu-0001We-Sm for tcpm@ietf.org; Tue, 18 Jul 2006 09:42:08 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6IDfMH09780; Tue, 18 Jul 2006 06:41:22 -0700 (PDT) Message-ID: <44BCE4FA.1050602@isi.edu> Date: Tue, 18 Jul 2006 06:41:14 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861619968==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0861619968== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8BF0033BABC04889A662E855" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8BF0033BABC04889A662E855 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 01:56 17/07/2006, Joe Touch wrote: >=20 >> > You could also add that, fortunately, virtually every implementation= >> has >> > mitigated the ICMP attacks described in >> > draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not al= l) >> > the counter-measures described in that draft. >> >> That last point doesn't obviate the issue that ICMP packets - even >> validated by the mitigations in the draft above - are still easier to >> spoof and can be spoofed by third parties than any of the attacks in >> tcp-secure. >=20 > The counter-measures in the ICMP attacks draft eliminate the ICMP-based= > connection reset, eliminate the Source Quench attack, and require the > attacker to be a Man In the Middle (*) for him to successfully perform > an attack against the PMTUD mechanism. The countermeasures there also violate the specific text in RFC1122, *without* noting (as per my other email) the "particular circumstances". Instead, it makes the general recommendation to change hard to soft error= s. I've repeatedly said that the text below directly negates the requirement in RFC1122. That NEEDS to be directly highlighted in your doc (the text that says that 1122 allows this is incorrect): "For security reasons, it would be fair to treat ICMP port unreachable messages as soft errors (or completely ignore them) when they are meant for protocols that have their own mechanism for reporting this error condition." Again, I'm not going to debate this further either. I'll be glad to remind the ADs during review; if they agree, fine. > It is clear that with the ICMP counter-measures in place, TCP-based > attacks are "the weakest link in the change". You don't need to "drop > them all". Even as soft errors, such ICMP errors could be interpreted by the application as indicating a legitimate error that causes the connection to be dropped, even though the only reason is attack. However, perhaps I'm speaking more of what the ICMP draft should be corrected to be, rather than what it is ;-) Short of changing RFC1122, you're stuck regarding hard errors and resets, due (notably) to the DIRECT LANGUAGE in 1122 that equates the two. Joe --------------enig8BF0033BABC04889A662E855 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvOT7E5f5cImnZrsRApt6AKCL4G7cAUaPwS8zru924P1TwEIZMwCfTPu4 5STwNE4MmmV/a3S+gCQyInE= =Eq7X -----END PGP SIGNATURE----- --------------enig8BF0033BABC04889A662E855-- --===============0861619968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0861619968==-- From tcpm-bounces@ietf.org Tue Jul 18 11:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rO2-0006V0-Hj; Tue, 18 Jul 2006 11:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rO1-0006Us-CM for tcpm@ietf.org; Tue, 18 Jul 2006 11:21:25 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rO0-000731-QQ for tcpm@ietf.org; Tue, 18 Jul 2006 11:21:25 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 18 Jul 2006 08:21:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IFLOK6024357; Tue, 18 Jul 2006 08:21:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6IFLO2D021202; Tue, 18 Jul 2006 08:21:24 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jul 2006 08:21:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05 Date: Tue, 18 Jul 2006 08:21:22 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801DF8915@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05 Thread-Index: AcaqbtFZaKpZaRwAQYiift1qfmSaFAACfWIw From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 18 Jul 2006 15:21:23.0932 (UTC) FILETIME=[D47E51C0:01C6AA7D] DKIM-Signature: a=rsa-sha1; q=dns; l=7513; t=1153236084; x=1154100084; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05; X=v=3Dcisco.com=3B=20h=3DCeksYhPTKiajql2H6p2yZiTQwso=3D; b=mg0WTakugcVuHLzbb/iFI6hAOvUN42ArYECVa/xwpysh0XsXQ/YQiS1RLK8a2b3QtPTry5ZU ptJ2+xlo4lThDpwa+FMEM4MDGBlqrh8wRHVtOybfaR+j7BeWzU4FeMrh; Authentication-Results: sj-dkim-2.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Tuesday, July 18, 2006 6:33 AM > To: Anantha Ramaiah (ananth) > Cc: Fernando Gont; tcpm@ietf.org > Subject: Re: [tcpm] feedcback on tcp-secure-05 >=20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Monday, July 17, 2006 7:31 AM > >> To: Anantha Ramaiah (ananth) > >> Cc: Fernando Gont; tcpm@ietf.org > >> Subject: Re: [tcpm] feedcback on tcp-secure-05 > >> > >> > >> > >> Anantha Ramaiah (ananth) wrote: > >> .. > >>> Another point to note is that TCP SHOULD act (not a MUST) on ICMP=20 > >>> reported hard errors. Also in some cases like "port > >> unreachable" can > >>> be ignored since TCP uses the RST for the purpose of port > >> unreachability. > >>> This is as per RFC 1122.=20 > >> 1122 actually states exactly the opposite: > >> > >> A transport protocol > >> that has its own mechanism for notifying the=20 > sender that a > >> port is unreachable (e.g., TCP, which sends=20 > RST segments) > >> MUST nevertheless accept an ICMP Port=20 > Unreachable for the > >> same purpose. > >=20 > > Yep, I stand corrected but one of main points above was to=20 > point out=20 > > the SHOULD language (which makes sense) instead of MUST. >=20 > So you're changing 1122? That needs to be highlighted. Nope, I was never advocating a change of RFC 1122. I was referring to the SHOULD language used in the RFC for treatment of 2,3 and 4 "hard errors" which also includes "port unreachable". 4.2.3.9 ICMP Messages ..... ..... o Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort the connection. Hope this is clear. >=20 > >>> - Some applications would chose to ignore the so called=20 > hard errors=20 > >>> for a TCP connection. In other words the behaviour can be > >> controlled > >>> by a CLI and the default would be to ignore this hard > >> errors. So the > >>> connection reset wouldn't happen. > >> The default SHOULD be to act on hard errors unless=20 > overridden by the=20 > >> application; to do otherwise would be to redefine 1122 in this=20 > >> regard. > >=20 > > Going neutral here, since the systems which I have worked do ignore=20 > > them by default and it isn't an RFC voilation. > >=20 > > As per RFC 2119 : > >=20 > > "3. SHOULD This word, or the adjective "RECOMMENDED",=20 > mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course." > >=20 > > Most of the applications would like to have a say in the=20 > treatment of=20 > > ICMP errors by requesting the errors to be passed to it and then=20 > > determine the course of action to take. For the ICMP hard errors=20 > > described, the action generally doesn't result in=20 > connection closure=20 > > and also some applications don't even register for some of the hard=20 > > errors and also expect TCP not to close the connection instead=20 > > silently ignore them >=20 > 1122 fairly directly indicates that ICMP port unreachable=20 > MUST be handled exactly as a RST ("accept for the same purpose"). I agree that it says "accept for same purpose". But it also goes ahead to suggest the "hard errors" SHOULD abort the connection instead of MUST and the hard errors include the "port unreachable". I don't want to argue further on this and I'll stick my point that applications today (in many implementations) has a say in interpreting the ICMP hard errors and it does not voilate RFC 1122. >=20 > A SHOULD would be a change to that, and needs to be=20 > highlighted as a change to 1122. We aren't changing the RFC 1122 language inside tcp-secure. I brought this up to highlight that ICMP errors can be blocked by configuration, firewalls etc.,.. >=20 > Further, as you note above, negating a should implies that=20 > the document indicate the "particular circumstances" that=20 > apply. The doc doesn't currently discuss interpreting=20 > violating messages as an attack and after a threshold is=20 > reached THEN negating the SHOULD. That's key. >=20 >=20 > > Actually application or TCP level keepalives or retransmission=20 > > timeouts act as a catalyst for the connection closure generally and=20 > > not ICMP errors. But YMMV and I do not intend to argue on=20 > this point.=20 > > Just stating my experience. > >=20 > >> ... > >>> I guess my point is ICMP attacks may be a weakest link, but > >> wouldn't > >>> cause connection resets with proper installed workarounds=20 > in place.=20 > >>> Yes, I mean without voilating the current RFC's. > >> Those workarounds MUST be in place, or they ARE the weakest link.=20 > >> That's the point that this document must discuss at least. > >=20 > > I don't think that tcpsecure document should discuss these=20 > workarounds=20 > > or advise anything of that sort. It is always good to keep=20 > the scope=20 > > of the document right and tight. >=20 > "right and tight" isn't a justification for not discussing=20 > the "particular circumstances" above. Justification for not discussing are pretty straightforward : We feel that it does not fir into the scope the document and adding that would only cause incompleteness to the document. >=20 > >>> Also with or without ICMP mitigations in place, one could > >> still cause > >>> a TCP connection to RESET, if the mitigations described in > >> tcp-secure > >>> isn't present. > >> Without ICMP protection, why bother with a RST when the ICMP is=20 > >> _easier_ to generate? > >=20 > > Easier to generate but workarounds can be planted if=20 > necessary like I=20 > > have described in earlier emails. On the other hand there=20 > aren't any=20 > > known "generic workarounds" available for the issues described in=20 > > tcp-secure. I say generic workarounds since MD5 is used only by a=20 > > handful of applications like BGP, LDP and is a costly workaround and > >=20 > > Anyways just to summarize : > >=20 > > The tcp-secure document, can, at the most state something=20 > informative=20 > > like "ICMP attacks aren't covered in this document blah=20 > blah..." and=20 > > provide a pointer to the icmp draft if needed. > >=20 > > To suggest about blocking ICMP etc., calls for stretching=20 > too far the=20 > > scope of the doc and also it introduces obvious incompleteness. >=20 > I'm not going to debate this further. I'll be glad to note=20 > the omission to the Security AD; if they think this doc is=20 > useful without it, fine. Ok. We would be glad to incorporate suggestions on ICMP blocking in the tcp-secure document if there is consensus in the WG list. As it stands now (based on the emails), the general feeling seems the other way round ie., not to talk about blocking etc., So, lets keep it simple. Thanks for the discussion though. -Anantha >=20 > > What if > > somebody wants to provide some pointer and suggest some=20 > > blocking/mitigation mechanisms for something else..? I see=20 > no end to=20 > > this that way.. > >=20 > > Agree/dis-agree ? > >=20 > > :) > > -Anantha > >> Joe > >> > >> >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 14:19:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2uA8-0005dr-BR; Tue, 18 Jul 2006 14:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2uA7-0005dm-Vk for tcpm@ietf.org; Tue, 18 Jul 2006 14:19:15 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2uA5-0003JH-Ip for tcpm@ietf.org; Tue, 18 Jul 2006 14:19:15 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6IIIqu15858 for ; Tue, 18 Jul 2006 11:18:52 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k6IIIqRL051687 for tcpm@ietf.org; Tue, 18 Jul 2006 11:18:52 -0700 (PDT) (envelope-from faber) Date: Tue, 18 Jul 2006 11:18:52 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text Message-ID: <20060718181852.GC50683@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060717180238.GE38453@hut.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1780366744==" Errors-To: tcpm-bounces@ietf.org --===============1780366744== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline --yudcn1FV7Hsu/q59 Content-Type: multipart/mixed; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've attached some text that I'd like to propose for the Security Considerations secition of this draft in an effort to make its scope clear and hopefully address some of Joe's concerns about ICMP. This is just me, a participant, making the suggestion. Text is attached. Let me know what you think. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tcpsec Implementors should be aware that the attacks detailed in this specification are not the only attacks available to an off-path attacker and that the countermeasures described herein are not a comprehensive defense against such attacks. In particular, administrators should be aware that forged ICMP messages provide off-path attackers the opportunity to disrupt connections or degrade service. Such attacks may be subject to even less scrutiny than the TCP attacks addressed here, especially in stacks not tuned for hostile environments. Section 6.1 of RFC4301 describes the issues associated with unauthenticated ICMP messages, e.g., messages from an off-path attacker, and is a good starting point for formulating a policy on those messages. In any case, this RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP. Administrators and implementors should consider the other attack vectors and determine appropriate mitigations in securing their systems. --Sr1nOIr3CvdE5hEN-- --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvSYMaUz3f+Zf+XsRAomNAKC7zd2Yj9wFs7lR8lYelKXjxS+pYwCgqmkm +bDVlrt1MV+KiSCrPE63rPY= =F3bI -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- --===============1780366744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1780366744==-- From tcpm-bounces@ietf.org Tue Jul 18 14:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2uHh-0001Bb-Sf; Tue, 18 Jul 2006 14:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2uHg-0001BW-Kt for tcpm@ietf.org; Tue, 18 Jul 2006 14:27:04 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2uHg-0003xP-5w for tcpm@ietf.org; Tue, 18 Jul 2006 14:27:04 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6IIR04l014991; Tue, 18 Jul 2006 21:27:00 +0300 Date: Tue, 18 Jul 2006 21:27:00 +0300 (EEST) From: Pekka Savola To: Ted Faber Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text In-Reply-To: <20060718181852.GC50683@hut.isi.edu> Message-ID: References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1600/Sat Jul 15 18:03:46 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, 18 Jul 2006, Ted Faber wrote: > I've attached some text that I'd like to propose for the Security > Considerations secition of this draft in an effort to make its scope > clear and hopefully address some of Joe's concerns about ICMP. > > This is just me, a participant, making the suggestion. > > Text is attached. Let me know what you think. I'm having practical problems with the second paragraph (the rest looks OK). It seems to imply that RFC 4301 adequately discusses the issues and is a useful starting point for developing a prevention policy _in practice_ (as very few sessions can use IPsec to prevent from ICMP attacks). My belief is that both of these implications are incorrect. On the other hand, I'd replace the text with references to tcpm-antispoof and tcpm-icmp-attacks which both go to some length in discussing this issue. The former could be cited in the first paragraph, the latter provided as a main discussion of ICMP attacks in the second paragraph. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 15:55:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vfP-0005W8-Ol; Tue, 18 Jul 2006 15:55:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vfN-0005Vq-RK for tcpm@ietf.org; Tue, 18 Jul 2006 15:55:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2v8k-000292-D4 for tcpm@ietf.org; Tue, 18 Jul 2006 15:21:54 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2v0Z-0003E1-66 for tcpm@ietf.org; Tue, 18 Jul 2006 15:13:29 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2006 12:13:27 -0700 X-IronPort-AV: i="4.06,255,1149490800"; d="scan'208"; a="434990782:sNHT28710812" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IJDQGo013147; Tue, 18 Jul 2006 12:13:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6IJDQJk024788; Tue, 18 Jul 2006 12:13:26 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 12:13:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] feedcback on tcp-secure-05: suggested text Date: Tue, 18 Jul 2006 12:13:24 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801DF8A70@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedcback on tcp-secure-05: suggested text Thread-Index: AcaqmCopm8mtspm1S8ShhoMXTZPpQwAAsg/Q From: "Anantha Ramaiah \(ananth\)" To: "Ted Faber" , X-OriginalArrivalTime: 18 Jul 2006 19:13:25.0991 (UTC) FILETIME=[3EAFEF70:01C6AA9E] DKIM-Signature: a=rsa-sha1; q=dns; l=1677; t=1153250006; x=1154114006; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05=3A=20suggested=20text; X=v=3Dcisco.com=3B=20h=3D5Xe8g444+k3iNGnfr28YXh/yDQA=3D; b=kZOAViokTfd5xA8hwNyskD9tcBdFYK5QtXY799RPHEBSFI2jEUStknB1PH56TJx8J/GDyFf5 EVQQHZ2CiAlxvTHyzws1juaN+0kLKerj6QJgRaDDiGvP5+Cs4r1FdMEy; Authentication-Results: sj-dkim-4.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted, The text looks good. A small suggestion which I think would draw the line even better : (Just taking an example : Pls see the text in quotes inserted the last paragraph from your proposal below]=20 In any case, this RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP. "This document focusses on dealing with some TCP segment based attack vectors and not other protocol packets"=20 Administrators and implementors should consider the other attack vectors and determine appropriate mitigations in securing their systems.=20 Since this document isn't a "cookbook" of all possible attacks on the TCP layer and the mitigations, saying something of this sort would help in containing the scope of the document better.=20 It is just my opinion I also think that there is scope of re-wording the sentence better. Thanks, -Anantha > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU]=20 > Sent: Tuesday, July 18, 2006 11:19 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text >=20 > I've attached some text that I'd like to propose for the=20 > Security Considerations secition of this draft in an effort=20 > to make its scope clear and hopefully address some of Joe's=20 > concerns about ICMP. >=20 > This is just me, a participant, making the suggestion. >=20 > Text is attached. Let me know what you think. >=20 > -- > Ted Faber > http://www.isi.edu/~faber PGP:=20 > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See=20 > http://www.isi.edu/~faber/FAQ.html#SIG >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 15:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vgZ-0005jO-1L; Tue, 18 Jul 2006 15:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vgY-0005jJ-1Q for tcpm@ietf.org; Tue, 18 Jul 2006 15:56:50 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vgW-0000Cj-MF for tcpm@ietf.org; Tue, 18 Jul 2006 15:56:50 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6IJthH10698; Tue, 18 Jul 2006 12:55:43 -0700 (PDT) Message-ID: <44BD3CBA.8060304@isi.edu> Date: Tue, 18 Jul 2006 12:55:38 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1879321844==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1879321844== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig620333D411F0C07692764EAD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig620333D411F0C07692764EAD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Tue, 18 Jul 2006, Ted Faber wrote: >> I've attached some text that I'd like to propose for the Security >> Considerations secition of this draft in an effort to make its scope >> clear and hopefully address some of Joe's concerns about ICMP. >> >> This is just me, a participant, making the suggestion. >> >> Text is attached. Let me know what you think. >=20 > I'm having practical problems with the second paragraph (the rest looks= > OK). It seems to imply that RFC 4301 adequately discusses the issues > and is a useful starting point for developing a prevention policy _in > practice_ (as very few sessions can use IPsec to prevent from ICMP > attacks). My belief is that both of these implications are incorrect. 6.1.1 might be the more relevant particular section; it talks about receipt of unprotected (un-IPsec'd) ICMPs. > On the other hand, I'd replace the text with references to > tcpm-antispoof and tcpm-icmp-attacks which both go to some length in > discussing this issue. The former could be cited in the first > paragraph, the latter provided as a main discussion of ICMP attacks in > the second paragraph. The other references might be useful, but pointing directly to 6.1.1 is less indirect and more to the point about the tradeoff of protection vs. responsiveness. Joe --------------enig620333D411F0C07692764EAD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvTy6E5f5cImnZrsRAn8KAJ4otRKXffK03/CiRh6zINpNV++EkQCfcc0h tdhaFw/g25hb4gCDCw16lps= =Snyg -----END PGP SIGNATURE----- --------------enig620333D411F0C07692764EAD-- --===============1879321844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1879321844==-- From tcpm-bounces@ietf.org Tue Jul 18 16:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vu2-0007RV-7c; Tue, 18 Jul 2006 16:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vu0-0007RN-R3 for tcpm@ietf.org; Tue, 18 Jul 2006 16:10:45 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vty-0002XS-5Y for tcpm@ietf.org; Tue, 18 Jul 2006 16:10:44 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6IJr6EJ006294; Tue, 18 Jul 2006 16:53:07 -0300 Message-Id: <7.0.1.0.0.20060718161825.04c116c8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 16:20:29 -0300 To: Pekka Savola , Ted Faber From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text In-Reply-To: References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:27 18/07/2006, Pekka Savola wrote: >On Tue, 18 Jul 2006, Ted Faber wrote: >>I've attached some text that I'd like to propose for the Security >>Considerations secition of this draft in an effort to make its scope >>clear and hopefully address some of Joe's concerns about ICMP. [....] >I'm having practical problems with the second paragraph (the rest >looks OK). It seems to imply that RFC 4301 adequately discusses the >issues and is a useful starting point for developing a prevention >policy _in practice_ (as very few sessions can use IPsec to prevent >from ICMP attacks). My belief is that both of these implications >are incorrect. > >On the other hand, I'd replace the text with references to >tcpm-antispoof and tcpm-icmp-attacks which both go to some length in >discussing this issue. The former could be cited in the first >paragraph, the latter provided as a main discussion of ICMP attacks >in the second paragraph. FWIW, I second Pekka's opinion. (As a matter of fact, what to do even in the case of IPSec'ed conenctions, is, IMO, up to the interpretation of who reads the IPSec spec.) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 16:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w5R-0002IZ-Qj; Tue, 18 Jul 2006 16:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w5Q-0002IU-QR for tcpm@ietf.org; Tue, 18 Jul 2006 16:22:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2w5P-0002x0-Cb for tcpm@ietf.org; Tue, 18 Jul 2006 16:22:32 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 18 Jul 2006 13:22:30 -0700 X-IronPort-AV: i="4.06,255,1149490800"; d="scan'208"; a="1839630781:sNHT26583896" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IKMUlk011555; Tue, 18 Jul 2006 13:22:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6IKMU79029994; Tue, 18 Jul 2006 13:22:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 13:22:30 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 13:22:29 -0700 Message-ID: <44BD430B.50401@cisco.com> Date: Tue, 18 Jul 2006 16:22:35 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> In-Reply-To: <20060718181852.GC50683@hut.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2006 20:22:30.0168 (UTC) FILETIME=[E4CF2980:01C6AAA7] DKIM-Signature: a=rsa-sha1; q=dns; l=2203; t=1153254150; x=1154118150; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[tcpm]=20feedcback=20on=20tcp-secure-05=3A=20suggested=20text; X=v=3Dcisco.com=3B=20h=3DOVpHT6NinKlng9MllXpBrxl2DH8=3D; b=WuNJseyRO01JlfquwltJVvchzxPLToS8hRzJ2regbpqFRIYhhZ8gorflKKwhiTEUBrPzh3V9 2b03kl66iDXZMJK6I7arK/PgLtwtC95gN2suER3YheSSqh/jwLsUsBx/; Authentication-Results: sj-dkim-6.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted/All: With the minor tweak of pointing directly to 6.1.1 .. I think what you have proposed is the right set of wording.. Getting bogged down in a ICMP attack issues disortation is silly and detracts from what we are trying to do... get tcp-secure finished... We can have a food-fight over the ICMP attacks document in the space of that document... R Ted Faber wrote: > I've attached some text that I'd like to propose for the Security > Considerations secition of this draft in an effort to make its scope > clear and hopefully address some of Joe's concerns about ICMP. > > This is just me, a participant, making the suggestion. > > Text is attached. Let me know what you think. > > > > ------------------------------------------------------------------------ > > > > Implementors should be aware that the attacks detailed in this > specification are not the only attacks available to an off-path attacker > and that the countermeasures described herein are not a comprehensive > defense against such attacks. > > In particular, administrators should be aware that forged ICMP messages > provide off-path attackers the opportunity to disrupt connections or > degrade service. Such attacks may be subject to even less scrutiny than > the TCP attacks addressed here, especially in stacks not tuned for > hostile environments. Section 6.1 of RFC4301 describes the issues > associated with unauthenticated ICMP messages, e.g., messages from an > off-path attacker, and is a good starting point for formulating a policy > on those messages. > > In any case, this RFC details only part of a complete strategy to > prevent off-path attackers from disrupting services that use TCP. > Administrators and implementors should consider the other attack vectors > and determine appropriate mitigations in securing their systems. > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 17:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2woZ-0007xV-Cv; Tue, 18 Jul 2006 17:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2woY-0007tq-2T for tcpm@ietf.org; Tue, 18 Jul 2006 17:09:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vqg-0002QA-No for tcpm@ietf.org; Tue, 18 Jul 2006 16:07:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2viP-0004Lb-CS for tcpm@ietf.org; Tue, 18 Jul 2006 15:58:47 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6IJvdH11005; Tue, 18 Jul 2006 12:57:39 -0700 (PDT) Message-ID: <44BD3D2E.2070000@isi.edu> Date: Tue, 18 Jul 2006 12:57:34 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> In-Reply-To: <20060718181852.GC50683@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.5 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1766226964==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1766226964== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig283EDCD13535DD5C2EB94684" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig283EDCD13535DD5C2EB94684 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > I've attached some text that I'd like to propose for the Security > Considerations secition of this draft in an effort to make its scope > clear and hopefully address some of Joe's concerns about ICMP. >=20 > This is just me, a participant, making the suggestion. >=20 > Text is attached. Let me know what you think. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 >=20 >=20 > Implementors should be aware that the attacks detailed in this > specification are not the only attacks available to an off-path attacke= r > and that the countermeasures described herein are not a comprehensive > defense against such attacks. >=20 > In particular, administrators should be aware that forged ICMP messages= > provide off-path attackers the opportunity to disrupt connections or > degrade service. Such attacks may be subject to even less scrutiny tha= n > the TCP attacks addressed here, especially in stacks not tuned for > hostile environments. Section 6.1 of RFC4301 describes the issues > associated with unauthenticated ICMP messages, e.g., messages from an > off-path attacker, and is a good starting point for formulating a polic= y > on those messages. I'd say 6.1.1 is more relevant; 6.1 as a whole also addresses ICMPs from inside protected boundaries, which is not applicable outside IPsec. > In any case, this RFC details only part of a complete strategy to > prevent off-path attackers from disrupting services that use TCP. > Administrators and implementors should consider the other attack vector= s > and determine appropriate mitigations in securing their systems. Modulo above, that looks fine to me. Joe --------------enig283EDCD13535DD5C2EB94684 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvT0uE5f5cImnZrsRApcLAKDqw2yFQutT7vahuw1a1I5Y9K1j3ACg4dxM jqAe+WlbZJk5JcyxFKkr4Tc= =GEe0 -----END PGP SIGNATURE----- --------------enig283EDCD13535DD5C2EB94684-- --===============1766226964== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1766226964==-- From tcpm-bounces@ietf.org Tue Jul 18 17:15:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wv0-0000SJ-4O; Tue, 18 Jul 2006 17:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wuz-0000SE-HF for tcpm@ietf.org; Tue, 18 Jul 2006 17:15:49 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2wuw-0008Tj-TT for tcpm@ietf.org; Tue, 18 Jul 2006 17:15:49 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6ILFiBF028597; Tue, 18 Jul 2006 18:15:46 -0300 Message-Id: <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 17:45:07 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 In-Reply-To: <44BCE4FA.1050602@isi.edu> References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 10:41 18/07/2006, Joe Touch wrote: [Talking about the ICMP attacks draft] >I've repeatedly said that the text below directly negates the >requirement in RFC1122. That NEEDS to be directly highlighted in your >doc (the text that says that 1122 allows this is incorrect): > > "For security reasons, > it would be fair to treat ICMP port unreachable messages as soft > errors (or completely ignore them) when they are meant for > protocols that have their own mechanism for reporting this error > condition." Joe, this already was in my list of changes. There are a bunch of comments from Mark, Pyda, Fred, you and others that I will (hopefully) address in the next revision of the draft. Now, as per Anatha's e-mails, there's ambiguity in RFC 1122 respect to this issue. There's a MUST and a SHOULD on the issue of what is supposed to be the correct reaction to a port unreachable. So, would you agree with the draft mentioning the ambiguity, and, as in the case of the other ICMP error codes, stating why it would make sense to treat them as soft errors, instead? (The "SHOULD" allows for that, after all). > > It is clear that with the ICMP counter-measures in place, TCP-based > > attacks are "the weakest link in the change". You don't need to "drop > > them all". > >Even as soft errors, such ICMP errors could be interpreted by the >application as indicating a legitimate error that causes the connection >to be dropped, even though the only reason is attack. This assumes that: a) The system in question does not honor the "recommendation" in the ICMP attacks draft b) ICMP error messages are passed to the application. In the Sockets API, they are passed only after a USER TIMEOUT. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 17:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wv1-0000U7-FM; Tue, 18 Jul 2006 17:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wv0-0000SO-89 for tcpm@ietf.org; Tue, 18 Jul 2006 17:15:50 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2wux-0008Tk-JU for tcpm@ietf.org; Tue, 18 Jul 2006 17:15:50 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6ILFiBH028597; Tue, 18 Jul 2006 18:15:47 -0300 Message-Id: <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 17:57:30 -0300 To: Randall Stewart , Ted Faber From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text In-Reply-To: <44BD430B.50401@cisco.com> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 17:22 18/07/2006, Randall Stewart wrote: >With the minor tweak of pointing directly to >6.1.1 .. I think what you have proposed is >the right set of wording. That document discusses ICMP in the context of IPSec'ed connections. If the connection is already secured by IPSec, you wouldn't bother about "in window" attacks. >Getting bogged down in a ICMP attack issues disortation >is silly and detracts from what we are trying to do... >get tcp-secure finished... Agreed. Given that the WG already has a document on this issue, it's probably better to provide a reference to that document, rather than trying to make recommendations from scratch. >We can have a food-fight over the ICMP attacks document >in the space of that document... FWIW, I'd be interested in not having such a fight over any of the two documents. Both of them are WG documents, and I'm interested in having both of them finished. Both in the case of tcpsecure (at least wrt the SYN-based and RST-based attacks) and the ICMP attacks draft, the industry has already implemented the counter-measures. Given that my opinion is already stated, I will focus on working on the drafts I still ahve to revise, and will refrain from adding anything else to this thread. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 17:23:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x2A-0001Bj-Ot; Tue, 18 Jul 2006 17:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x29-0001Be-Fj for tcpm@ietf.org; Tue, 18 Jul 2006 17:23:13 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x28-0000d9-2d for tcpm@ietf.org; Tue, 18 Jul 2006 17:23:13 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6ILN1u15536; Tue, 18 Jul 2006 14:23:01 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k6ILN1Y1055250; Tue, 18 Jul 2006 14:23:01 -0700 (PDT) (envelope-from faber) Date: Tue, 18 Jul 2006 14:23:01 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text Message-ID: <20060718212301.GE50683@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> Mime-Version: 1.0 In-Reply-To: <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Randall Stewart , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1846185303==" Errors-To: tcpm-bounces@ietf.org --===============1846185303== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kR3zbvD4cgoYnS/6" Content-Disposition: inline --kR3zbvD4cgoYnS/6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2006 at 05:57:30PM -0300, Fernando Gont wrote: > At 17:22 18/07/2006, Randall Stewart wrote: >=20 > >With the minor tweak of pointing directly to > >6.1.1 .. I think what you have proposed is > >the right set of wording. Yeah, I missed a "1". 6.1.1 is the section I wanted. >=20 > That document discusses ICMP in the context of IPSec'ed connections.=20 > If the connection is already secured by IPSec, you wouldn't bother=20 > about "in window" attacks. It does, but 6.1.1 talks about unauthenticated ICMP messages, which is exactly what the issue is here - there's no IPSec in play in this document so *all* ICMP is unauthenticated. With that understanding, which I tried to get across in my text, I think the discussion of the pros and cons of blocking ICMP is a pretty good primer to help people understand what they're getting into. The goal is to indicate that there are tradeoffs here, but that they're outside the scope of tcpsecure. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --kR3zbvD4cgoYnS/6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvVE1aUz3f+Zf+XsRAhiTAKDhJfj+NRoYdmUbOqvvnPTA0q1ZzwCgr9Jg 2KZ8f1Md2Dfn/+KHw/YWk1g= =jAjO -----END PGP SIGNATURE----- --kR3zbvD4cgoYnS/6-- --===============1846185303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1846185303==-- From tcpm-bounces@ietf.org Tue Jul 18 17:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x3i-0001OU-4k; Tue, 18 Jul 2006 17:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x3g-0001OP-Fp for tcpm@ietf.org; Tue, 18 Jul 2006 17:24:48 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x3f-0000oR-3K for tcpm@ietf.org; Tue, 18 Jul 2006 17:24:48 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6ILNWH01843; Tue, 18 Jul 2006 14:23:32 -0700 (PDT) Message-ID: <44BD514C.2090704@isi.edu> Date: Tue, 18 Jul 2006 14:23:24 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05 References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1368961918==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1368961918== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7EF9E1D4E61EA23FD9EC8106" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7EF9E1D4E61EA23FD9EC8106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 10:41 18/07/2006, Joe Touch wrote: >=20 > [Talking about the ICMP attacks draft] >=20 >> I've repeatedly said that the text below directly negates the >> requirement in RFC1122. That NEEDS to be directly highlighted in your >> doc (the text that says that 1122 allows this is incorrect): >> >> "For security reasons, >> it would be fair to treat ICMP port unreachable messages as soft= >> errors (or completely ignore them) when they are meant for >> protocols that have their own mechanism for reporting this error= >> condition." >=20 > Joe, this already was in my list of changes. There are a bunch of > comments from Mark, Pyda, Fred, you and others that I will (hopefully) > address in the next revision of the draft. >=20 > Now, as per Anatha's e-mails, there's ambiguity in RFC 1122 respect to > this issue. There's a MUST and a SHOULD on the issue of what is suppose= d > to be the correct reaction to a port unreachable. >=20 > So, would you agree with the draft mentioning the ambiguity, and, as in= > the case of the other ICMP error codes, stating why it would make sense= > to treat them as soft errors, instead? (The "SHOULD" allows for that, > after all). The specific reason and conditions for the SHOULD *must* (my must) be addressed, IMO (presumably "connect established" at least, or making forward progress at most - with caveats about change of behavior - for better or worse - in certain multipath scenarios as already raised). The existence of the ambiguity *must* also be specifically noted. If these are already repeating previous conclusions, that's fine. ;-) >> > It is clear that with the ICMP counter-measures in place, TCP-based >> > attacks are "the weakest link in the change". You don't need to "dro= p >> > them all". >> >> Even as soft errors, such ICMP errors could be interpreted by the >> application as indicating a legitimate error that causes the connectio= n >> to be dropped, even though the only reason is attack. >=20 > This assumes that: > a) The system in question does not honor the "recommendation" in the > ICMP attacks draft You're making recommendations about what the TCP should do regarding the errors; that's not the same as what the application on top of TCP would d= o. > b) ICMP error messages are passed to the application. In the Sockets > API, they are passed only after a USER TIMEOUT. I don't recall anything in 1122 about how quickly soft errors must be passed to the app, but they MUST be passed to the app. This implies that soft errors aren't passed if a user timeout doesn't occur, which seems like another violation that should be noted. Joe --------------enig7EF9E1D4E61EA23FD9EC8106 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvVFME5f5cImnZrsRAuzmAKDuEHPoZBe9wypl6HX2cMeZdwr/xwCgm2/t oczOWzkJ/E0CNQqnjkfsOes= =EpRr -----END PGP SIGNATURE----- --------------enig7EF9E1D4E61EA23FD9EC8106-- --===============1368961918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1368961918==-- From tcpm-bounces@ietf.org Tue Jul 18 17:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x4n-0001aT-4G; Tue, 18 Jul 2006 17:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x4l-0001aJ-EN for tcpm@ietf.org; Tue, 18 Jul 2006 17:25:55 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x4k-0000vp-3e for tcpm@ietf.org; Tue, 18 Jul 2006 17:25:55 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6ILOtH02066; Tue, 18 Jul 2006 14:24:55 -0700 (PDT) Message-ID: <44BD519F.6040905@isi.edu> Date: Tue, 18 Jul 2006 14:24:47 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Randall Stewart , tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0481452820==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0481452820== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B3BB29BE43048BD131E4A90" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B3BB29BE43048BD131E4A90 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 17:22 18/07/2006, Randall Stewart wrote: >=20 >> With the minor tweak of pointing directly to >> 6.1.1 .. I think what you have proposed is >> the right set of wording. >=20 > That document discusses ICMP in the context of IPSec'ed connections. If= > the connection is already secured by IPSec, you wouldn't bother about > "in window" attacks. Sec 6.1.1 discusses handling untrusted ICMPs. In a non-IPsec environment, all ICMPs fall into this category. Joe --------------enig3B3BB29BE43048BD131E4A90 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvVGfE5f5cImnZrsRAn8NAJ9EG267mvElqvhvKnukBhpfObdntgCg+vAy d3nrJCaneS5H/ZBtmtc1U1E= =tqed -----END PGP SIGNATURE----- --------------enig3B3BB29BE43048BD131E4A90-- --===============0481452820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0481452820==-- From tcpm-bounces@ietf.org Tue Jul 18 17:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xCz-0002Ye-EB; Tue, 18 Jul 2006 17:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xCy-0002YZ-Hw for tcpm@ietf.org; Tue, 18 Jul 2006 17:34:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2xCy-0001i7-3v for tcpm@ietf.org; Tue, 18 Jul 2006 17:34:24 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6ILWPu18146; Tue, 18 Jul 2006 14:32:25 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k6ILWPQ2055415; Tue, 18 Jul 2006 14:32:25 -0700 (PDT) (envelope-from faber) Date: Tue, 18 Jul 2006 14:32:25 -0700 From: Ted Faber To: Pekka Savola Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text Message-ID: <20060718213225.GF50683@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1099847832==" Errors-To: tcpm-bounces@ietf.org --===============1099847832== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kadn00tgSopKmJ1H" Content-Disposition: inline --kadn00tgSopKmJ1H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2006 at 09:27:00PM +0300, Pekka Savola wrote: > On Tue, 18 Jul 2006, Ted Faber wrote: > >I've attached some text that I'd like to propose for the Security > >Considerations secition of this draft in an effort to make its scope > >clear and hopefully address some of Joe's concerns about ICMP. > > > >This is just me, a participant, making the suggestion. > > > >Text is attached. Let me know what you think. >=20 > I'm having practical problems with the second paragraph (the rest=20 > looks OK). It seems to imply that RFC 4301 adequately discusses the=20 > issues and is a useful starting point for developing a prevention=20 > policy _in practice_ (as very few sessions can use IPsec to prevent=20 > from ICMP attacks). My belief is that both of these implications are=20 > incorrect. I don't get that from my text, and it's certainly not my intended meaning. The section (6.1.1, which si the one I should have pointed at) nicely describes how different classes of ICMP can help or hurt you and the tradeoffs of accepting them. The point of my text is that even if you implement tcpsecure, you're not done. You've got other worries from off-path attackers and ICMP is one of the big ones. I said it's a starting point, and I don't think it's more than that. I also don't think it's worth trying to solve that problem in this document, just point out to people securing their machines that they're not done yet. > On the other hand, I'd replace the text with references to=20 > tcpm-antispoof and tcpm-icmp-attacks which both go to some length in=20 > discussing this issue. The former could be cited in the first=20 > paragraph, the latter provided as a main discussion of ICMP attacks in=20 > the second paragraph. Anti-spoof should be referenced earlier on in the draft and I don't see the benefit of an additional reference here. If you'd like to provide edited text with the reference you want in it, feel free, though. I don't want to link this draft to icmp-attacks in a way that would slow this draft's publication. I think the ICMP issues are completely ancillary to this document. I think that noting that they exist is sufficient. In fact, I'm perfectly willing to delete the reference to 4301 and just say that while ICMP port unreachables can close connections, ICMP fragmentation required can keep your packets reasonably sized to go through the network. If you'd like that text polished, I can do it. Alternatively, I'm sure text containing the references you think are appropriate would be taken by the authors. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --kadn00tgSopKmJ1H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvVNpaUz3f+Zf+XsRAgU+AJwILEF6bYyqnjsrqc/4pBDkQ/E1JACgpwyd 4vyNEomNxwwAcGytMsRuz4E= =FH8y -----END PGP SIGNATURE----- --kadn00tgSopKmJ1H-- --===============1099847832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1099847832==-- From tcpm-bounces@ietf.org Tue Jul 18 18:42:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yGO-0003h2-BN; Tue, 18 Jul 2006 18:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yGM-0003gx-HC for tcpm@ietf.org; Tue, 18 Jul 2006 18:41:58 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2yGK-0006VK-St for tcpm@ietf.org; Tue, 18 Jul 2006 18:41:58 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6IMfnEH024436; Tue, 18 Jul 2006 19:41:50 -0300 Message-Id: <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 19:36:41 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <44BD514C.2090704@isi.edu> References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: [tcpm] ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:23 18/07/2006, Joe Touch wrote: [(was Re: [tcpm] feedcback on tcp-secure-05)] > > So, would you agree with the draft mentioning the ambiguity, and, as in > > the case of the other ICMP error codes, stating why it would make sense > > to treat them as soft errors, instead? (The "SHOULD" allows for that, > > after all). > >The specific reason and conditions for the SHOULD *must* (my must) be >addressed, IMO (presumably "connect established" at least, or making >forward progress at most - with caveats about change of behavior - for >better or worse - in certain multipath scenarios as already raised). Okay. So, * The condition for all the so-called hard errors to be treated as soft errors is that the conenction must be in any of the synchronized states. * The reason for not honoring the SHOULD is that in hostile environments, its an attack vector that is easier to perform than others. (I will note the ambiguity in the case of port unreachables) * The good thing of the change is that it mitigates the above threat, and also improves TCP's robustness in the case of multipath scenarios. Let me know if you agree with these and/or if I missed anything. > > This assumes that: > > a) The system in question does not honor the "recommendation" in the > > ICMP attacks draft > >You're making recommendations about what the TCP should do regarding the >errors; that's not the same as what the application on top of TCP would do. I think this would be out of the scope of the document? > > b) ICMP error messages are passed to the application. In the Sockets > > API, they are passed only after a USER TIMEOUT. > >I don't recall anything in 1122 about how quickly soft errors must be >passed to the app, but they MUST be passed to the app. This implies that >soft errors aren't passed if a user timeout doesn't occur, which seems >like another violation that should be noted. This seems out of scope, too. We are not doing anything new wrt to whether TCP should handle ICMP errors to applications or not. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 19:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2z4S-0003M0-H8; Tue, 18 Jul 2006 19:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2z4R-0003Lv-I7 for tcpm@ietf.org; Tue, 18 Jul 2006 19:33:43 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2z4P-0000q1-Tn for tcpm@ietf.org; Tue, 18 Jul 2006 19:33:43 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6INXYcN006602; Tue, 18 Jul 2006 20:33:34 -0300 Message-Id: <7.0.1.0.0.20060718201549.04c5bb78@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 20:32:01 -0300 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text In-Reply-To: <20060718212301.GE50683@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> <20060718212301.GE50683@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Randall Stewart , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:23 18/07/2006, Ted Faber wrote: > > That document discusses ICMP in the context of IPSec'ed connections. > > If the connection is already secured by IPSec, you wouldn't bother > > about "in window" attacks. > >It does, but 6.1.1 talks about unauthenticated ICMP messages, which is >exactly what the issue is here - there's no IPSec in play in this >document so *all* ICMP is unauthenticated. Section 6 says: " This section describes IPsec handling of ICMP traffic. There are two categories of ICMP traffic: error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages." And Section 6.1 (parent of Section 6.1.1 and Section 6.1.2) is entitled "Processing ICMP Error Messages Directed to an IPsec Implementation" I think this makes it perfectly clear that Section 6.1.1 is about unprotected ICMP messages *directed* to an *IPSec* implementation. FWIW, Section 5.2 ("Processing Inbound IP Traffic (unprotected-to-protected)") of RFC 4301 says: " 3c. Processing of ICMP messages is assumed to take place on the unprotected side of the IPsec boundary. Unprotected ICMP messages are examined and local policy is applied to determine whether to accept or reject these messages and, if accepted, what action to take as a result. For example, if an ICMP unreachable message is received, the implementation must decide whether to act on it, reject it, or act on it with constraints. (See Section 6.)" RFC 4301 never states that ICMP messages should be filtered. And its clear from this last paragraph that a number of behaviours (including "act on it with constraints") are among the possibilities. I don't want to slow tcpsecure, nor any other draft (as a matter of fact, I didn't raise the ICMP issue). Issue raised, I think it's appropriate to state that tcpsecure does not prevent ICMP attacks. And being that the WG has a document on that issue, it would make sense to reference it. It could something as simple as "This RFC does not prevent the ICMP based attacks discussed in [ICMP-Attacks]", where "ICMP-Attacks" is a reference to draft-ietf-tcpm-icmp-attacks. That said, I think that all this provides a hint that the ICMP issues should be fixed on Standards track. However, I have no intention on spending cycles to change the path of the ICMP attacks drafts. I raised the question in a separate e-mail, and, IIRC, there were others that stated they would be glad to actually modify the specs. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 19:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zO5-0005q5-HJ; Tue, 18 Jul 2006 19:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zO3-0005q0-V9 for tcpm@ietf.org; Tue, 18 Jul 2006 19:53:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2zO1-0002H1-H6 for tcpm@ietf.org; Tue, 18 Jul 2006 19:53:59 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6INqdH02739; Tue, 18 Jul 2006 16:52:39 -0700 (PDT) Message-ID: <44BD7441.9050206@isi.edu> Date: Tue, 18 Jul 2006 16:52:33 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1956249897==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1956249897== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBA1728ED61A81B598B24FCF6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA1728ED61A81B598B24FCF6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 18:23 18/07/2006, Joe Touch wrote: >=20 > [(was Re: [tcpm] feedcback on tcp-secure-05)] >=20 >> > So, would you agree with the draft mentioning the ambiguity, and, as= in >> > the case of the other ICMP error codes, stating why it would make se= nse >> > to treat them as soft errors, instead? (The "SHOULD" allows for that= , >> > after all). >> >> The specific reason and conditions for the SHOULD *must* (my must) be >> addressed, IMO (presumably "connect established" at least, or making >> forward progress at most - with caveats about change of behavior - for= >> better or worse - in certain multipath scenarios as already raised). >=20 > Okay. >=20 > So, >=20 > * The condition for all the so-called hard errors to be treated as soft= > errors is that the conenction must be in any of the synchronized states= =2E > * The reason for not honoring the SHOULD is that in hostile > environments, its an attack vector that is easier to perform than > others. (I will note the ambiguity in the case of port unreachables) > * The good thing of the change is that it mitigates the above threat, > and also improves TCP's robustness in the case of multipath scenarios. I agree with these. It would also be useful to add - to the last one - that this *changes* how TCP would behave in multipath scenarios and/or path changes, which *may* make TCP less likely to _correctly_ rapidly disconnect from a session when a routing change occurs that disconnects endpoints. (i.e., there are cases that this might not be the best choice; trading robustness for reactiveness to failure is typical, but not always the only choice). Joe >=20 > Let me know if you agree with these and/or if I missed anything. >=20 >=20 >=20 >> > This assumes that: >> > a) The system in question does not honor the "recommendation" in the= >> > ICMP attacks draft >> >> You're making recommendations about what the TCP should do regarding t= he >> errors; that's not the same as what the application on top of TCP >> would do. >=20 > I think this would be out of the scope of the document? >=20 >=20 >> > b) ICMP error messages are passed to the application. In the Sockets= >> > API, they are passed only after a USER TIMEOUT. >> >> I don't recall anything in 1122 about how quickly soft errors must be >> passed to the app, but they MUST be passed to the app. This implies th= at >> soft errors aren't passed if a user timeout doesn't occur, which seems= >> like another violation that should be noted. >=20 > This seems out of scope, too. We are not doing anything new wrt to > whether TCP should handle ICMP errors to applications or not. >=20 > Kindest regards, >=20 > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enigBA1728ED61A81B598B24FCF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvXRBE5f5cImnZrsRAifMAKC9TxGw3kFoRSuh2KkJBAEZwC12FgCg8WqM I6pMiOVF44GRMFIjHy7pjus= =zLhz -----END PGP SIGNATURE----- --------------enigBA1728ED61A81B598B24FCF6-- --===============1956249897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1956249897==-- From tcpm-bounces@ietf.org Tue Jul 18 20:09:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zc1-0007BC-R6; Tue, 18 Jul 2006 20:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zc0-0007B7-L6 for tcpm@ietf.org; Tue, 18 Jul 2006 20:08:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2zby-00031G-7y for tcpm@ietf.org; Tue, 18 Jul 2006 20:08:24 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6J07Su03191; Tue, 18 Jul 2006 17:07:28 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k6J07Slh087771; Tue, 18 Jul 2006 17:07:28 -0700 (PDT) (envelope-from faber) Date: Tue, 18 Jul 2006 17:07:28 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text Message-ID: <20060719000728.GT50683@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> <20060718212301.GE50683@hut.isi.edu> <7.0.1.0.0.20060718201549.04c5bb78@gont.com.ar> Mime-Version: 1.0 In-Reply-To: <7.0.1.0.0.20060718201549.04c5bb78@gont.com.ar> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Randall Stewart , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1009441644==" Errors-To: tcpm-bounces@ietf.org --===============1009441644== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rHeCoQbvuHTnkkIZ" Content-Disposition: inline --rHeCoQbvuHTnkkIZ Content-Type: multipart/mixed; boundary="eEYjL7b2m+/uQ8dh" Content-Disposition: inline --eEYjL7b2m+/uQ8dh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2006 at 08:32:01PM -0300, Fernando Gont wrote: > RFC 4301 never states that ICMP messages should be filtered. And its=20 > clear from this last paragraph that a number of behaviours (including=20 > "act on it with constraints") are among the possibilities. Fine. Try the attached. I'm happy to add an explicit reference to the attacks draft if it can be phrased in such a way that it does not link the publication of the two. Feel free to send text. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --eEYjL7b2m+/uQ8dh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tcpsec Implementors should be aware that the attacks detailed in this specification are not the only attacks available to an off-path attacker and that the countermeasures described herein are not a comprehensive defense against such attacks. In particular, administrators should be aware that forged ICMP messages provide off-path attackers the opportunity to disrupt connections or degrade service. Such attacks may be subject to even less scrutiny than the TCP attacks addressed here, especially in stacks not tuned for hostile environments. It is important to note that some ICMP messages, validated or not, are key to the proper function of TCP. Those ICMP messages used to properly set the path maximum transmission unit are the most obvious example. There are a variety of ways to choose which, if any, ICMP messages to trust in the presence of off-path attackers and choosing between them depends on the assumptions and guarantees developers and administrators can make about their network. This specification does not attempt to do more than note this and related issues. In any case, this RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP. Administrators and implementors should consider the other attack vectors and determine appropriate mitigations in securing their systems. --eEYjL7b2m+/uQ8dh-- --rHeCoQbvuHTnkkIZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvXfAaUz3f+Zf+XsRAkPCAJ0TZ803TGqSiOCZ/wb2CoR2ArjswwCg46A8 +5ndIu8Dlrmy/6PKdzIpWds= =z3Hl -----END PGP SIGNATURE----- --rHeCoQbvuHTnkkIZ-- --===============1009441644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1009441644==-- From tcpm-bounces@ietf.org Tue Jul 18 20:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3075-0000hX-QM; Tue, 18 Jul 2006 20:40:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3075-0000hS-97 for tcpm@ietf.org; Tue, 18 Jul 2006 20:40:31 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3073-0004oo-Lk for tcpm@ietf.org; Tue, 18 Jul 2006 20:40:31 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6J0eOjH004712; Tue, 18 Jul 2006 21:40:29 -0300 Message-Id: <7.0.1.0.0.20060718211858.05384d00@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 21:37:28 -0300 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text In-Reply-To: <20060719000728.GT50683@hut.isi.edu> References: <44B682AB.9010702@isi.edu> <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> <20060718212301.GE50683@hut.isi.edu> <7.0.1.0.0.20060718201549.04c5bb78@gont.com.ar> <20060719000728.GT50683@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Randall Stewart , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 21:07 18/07/2006, Ted Faber wrote: >On Tue, Jul 18, 2006 at 08:32:01PM -0300, Fernando Gont wrote: > > RFC 4301 never states that ICMP messages should be filtered. And its > > clear from this last paragraph that a number of behaviours (including > > "act on it with constraints") are among the possibilities. > >Fine. Try the attached. > >I'm happy to add an explicit reference to the attacks draft if it can be >phrased in such a way that it does not link the publication of the two. >Feel free to send text. I'd change the text to: "Implementors should be aware that the attacks detailed in this specification are not the only attacks available to an off-path attacker and that the countermeasures described herein are not a comprehensive defense against such attacks. In particular, administrators should be aware that forged ICMP messages provide off-path attackers the opportunity to disrupt connections or degrade service. Such packets may be subject to even less scrutiny than those required for the TCP attacks addressed here, especially in stacks not tuned for hostile environments. This RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP. Administrators and implementors should consider the other attack vectors and determine appropriate mitigations in securing their systems. [antispoof] provides a detailed discussion of TCP attacks based on forged TCP segments, along with a discussion on the possible counter-measures. [ICMP-attacks] provides a detailed discussion on TCP attacks based on forged ICMP packets, along with the possible counter-measures." Note that I basically removed text, and added references. And that the references are included in a way in which there's no "requirement". Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 18 20:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30Pl-0002V0-21; Tue, 18 Jul 2006 20:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30Pk-0002Uu-1J for tcpm@ietf.org; Tue, 18 Jul 2006 20:59:48 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G30Ph-0005pN-KK for tcpm@ietf.org; Tue, 18 Jul 2006 20:59:48 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6J0wCu15657; Tue, 18 Jul 2006 17:58:12 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k6J0wC5w096778; Tue, 18 Jul 2006 17:58:12 -0700 (PDT) (envelope-from faber) Date: Tue, 18 Jul 2006 17:58:12 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] feedcback on tcp-secure-05: suggested text Message-ID: <20060719005812.GW50683@hut.isi.edu> References: <7.0.1.0.0.20060715162015.085dce90@gont.com.ar> <44BB1965.9070305@isi.edu> <20060717180238.GE38453@hut.isi.edu> <20060718181852.GC50683@hut.isi.edu> <44BD430B.50401@cisco.com> <7.0.1.0.0.20060718174534.04c68e68@gont.com.ar> <20060718212301.GE50683@hut.isi.edu> <7.0.1.0.0.20060718201549.04c5bb78@gont.com.ar> <20060719000728.GT50683@hut.isi.edu> <7.0.1.0.0.20060718211858.05384d00@gont.com.ar> Mime-Version: 1.0 In-Reply-To: <7.0.1.0.0.20060718211858.05384d00@gont.com.ar> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Randall Stewart , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2096870777==" Errors-To: tcpm-bounces@ietf.org --===============2096870777== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hblleJHDxiLJUoyx" Content-Disposition: inline --hblleJHDxiLJUoyx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2006 at 09:37:28PM -0300, Fernando Gont wrote: > At 21:07 18/07/2006, Ted Faber wrote: >=20 > >On Tue, Jul 18, 2006 at 08:32:01PM -0300, Fernando Gont wrote: > >> RFC 4301 never states that ICMP messages should be filtered. And its > >> clear from this last paragraph that a number of behaviours (including > >> "act on it with constraints") are among the possibilities. > > > >Fine. Try the attached. > > > >I'm happy to add an explicit reference to the attacks draft if it can be > >phrased in such a way that it does not link the publication of the two. > >Feel free to send text. >=20 > I'd change the text to: >=20 > "Implementors should be aware that the attacks detailed in this > specification are not the only attacks available to an off-path attacker > and that the countermeasures described herein are not a comprehensive > defense against such attacks. >=20 > In particular, administrators should be aware that forged ICMP messages > provide off-path attackers the opportunity to disrupt connections or > degrade service. Such packets may be subject to even less scrutiny than > those required for the TCP attacks addressed here, especially in=20 > stacks not tuned for > hostile environments. >=20 > This RFC details only part of a complete strategy to > prevent off-path attackers from disrupting services that use TCP. > Administrators and implementors should consider the other attack vectors > and determine appropriate mitigations in securing their systems. >=20 > [antispoof] provides a detailed discussion of TCP attacks based on=20 > forged TCP segments, along with > a discussion on the possible counter-measures. [ICMP-attacks]=20 > provides a detailed discussion on TCP attacks based > on forged ICMP packets, along with the possible counter-measures." >=20 >=20 > Note that I basically removed text, and added references. And that=20 > the references are included in a way in which there's no "requirement". As long as neither of those refs imposes dependencies on tcpsecure, I'm delighted with the text. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --hblleJHDxiLJUoyx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvYOkaUz3f+Zf+XsRAqlnAJ46nv3I3oi7ARy4SYN6T2KMgj2cowCg4OBK Hhjrdsj227ay/YLIjjDnjRo= =+rf3 -----END PGP SIGNATURE----- --hblleJHDxiLJUoyx-- --===============2096870777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2096870777==-- From tcpm-bounces@ietf.org Wed Jul 19 02:37:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35gO-0001lk-OO; Wed, 19 Jul 2006 02:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35gM-0001lf-W9 for tcpm@ietf.org; Wed, 19 Jul 2006 02:37:18 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G35gK-0000ZT-C4 for tcpm@ietf.org; Wed, 19 Jul 2006 02:37:18 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6J6alYR026419; Wed, 19 Jul 2006 03:37:14 -0300 Message-Id: <7.0.1.0.0.20060719031923.04a637f0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 19 Jul 2006 03:26:37 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft In-Reply-To: <44BD7441.9050206@isi.edu> References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> <44BD7441.9050206@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 20:52 18/07/2006, Joe Touch wrote: > > * The condition for all the so-called hard errors to be treated as soft > > errors is that the conenction must be in any of the synchronized states. > > * The reason for not honoring the SHOULD is that in hostile > > environments, its an attack vector that is easier to perform than > > others. (I will note the ambiguity in the case of port unreachables) > > * The good thing of the change is that it mitigates the above threat, > > and also improves TCP's robustness in the case of multipath scenarios. > >I agree with these. It would also be useful to add - to the last one - >that this *changes* how TCP would behave in multipath scenarios and/or >path changes, which *may* make TCP less likely to _correctly_ rapidly >disconnect from a session when a routing change occurs that disconnects >endpoints. > >(i.e., there are cases that this might not be the best choice; trading >robustness for reactiveness to failure is typical, but not always the >only choice). I understand what you mean. However, the message codes to which we are changing from hard to soft errors (protocol unreachable and port unreachable) are not the ones that would reflect a routing change. In the case of ICMP frag needed (if TCP does not implement PMTUD), it might be an indication of a routing change. Although implementing TCP without PMTUD, and at the same time setting the DF bit in the packets seems to me, at the very least, very weird. Or am I missing something? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 19 11:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DlZ-00029e-Lh; Wed, 19 Jul 2006 11:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DlY-00029Y-2x for tcpm@ietf.org; Wed, 19 Jul 2006 11:15:12 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DlW-0001jL-MN for tcpm@ietf.org; Wed, 19 Jul 2006 11:15:12 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6JFDnH18792; Wed, 19 Jul 2006 08:13:49 -0700 (PDT) Message-ID: <44BE4C27.1010600@isi.edu> Date: Wed, 19 Jul 2006 08:13:43 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> <44BD7441.9050206@isi.edu> <7.0.1.0.0.20060719031923.04a637f0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060719031923.04a637f0@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125253268==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1125253268== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBA7AD65F9C4A3CE22F7935A8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA7AD65F9C4A3CE22F7935A8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 20:52 18/07/2006, Joe Touch wrote: >=20 >> > * The condition for all the so-called hard errors to be treated as s= oft >> > errors is that the conenction must be in any of the synchronized >> states. >> > * The reason for not honoring the SHOULD is that in hostile >> > environments, its an attack vector that is easier to perform than >> > others. (I will note the ambiguity in the case of port unreachables)= >> > * The good thing of the change is that it mitigates the above threat= , >> > and also improves TCP's robustness in the case of multipath scenario= s. >> >> I agree with these. It would also be useful to add - to the last one -= >> that this *changes* how TCP would behave in multipath scenarios and/or= >> path changes, which *may* make TCP less likely to _correctly_ rapidly >> disconnect from a session when a routing change occurs that disconnect= s >> endpoints. >> >> (i.e., there are cases that this might not be the best choice; trading= >> robustness for reactiveness to failure is typical, but not always the >> only choice). >=20 > I understand what you mean. However, the message codes to which we are > changing from hard to soft errors (protocol unreachable and port > unreachable) are not the ones that would reflect a routing change. Sorry - long time since I got into this level of detail. We're talking about dest unreachable codes 2-4, i.e.: 2 protocol 3 port 4 frag needed and DF set Changing these from hard to soft AFTER connection establishment means: - slower reaction (if at all?) to host reconfiguration 2,3 - dynamic reloading of protocol module fails 3 - unexpected application termination (?) although TCP can send a RST in this case, ICMP should also generate port unreachable (?) Reloading protocols isn't unheard of (netgraph, etc.). Failure of that protocol has many consequences, and at some level nonresponsiveness is its own signal, but softening these signals basically means you are assuming that protocols don't change once a connection is up. That's a NEW assumption and should be noted. - slower/no reaction to path change 4 - change in path MTU > In the case of ICMP frag needed (if TCP does not implement PMTUD), it > might be an indication of a routing change. Although implementing TCP > without PMTUD, and at the same time setting the DF bit in the packets > seems to me, at the very least, very weird. This could indicate a new tunnel, turning on encryption, etc. too. And path changes happen. As to the case where ICMP Frag needed should generate a hard error, consider: - simple TCP stack that lacks PMTUD - an intermediate device sets the DF bit I saw that case a few years ago. Changing hard to soft changes reaction to that event. Joe --------------enigBA7AD65F9C4A3CE22F7935A8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvkwnE5f5cImnZrsRAlgnAKDS6NWyBTcUQknPhXoDDfc9GexJbgCeMSyj CIZJIyfYv1ajmuG94IW8pAA= =6aHy -----END PGP SIGNATURE----- --------------enigBA7AD65F9C4A3CE22F7935A8-- --===============1125253268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1125253268==-- From tcpm-bounces@ietf.org Wed Jul 19 17:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Jr5-0002Kf-Ok; Wed, 19 Jul 2006 17:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Jr3-0002Ja-Vc for tcpm@ietf.org; Wed, 19 Jul 2006 17:45:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3IQk-00007f-Qt; Wed, 19 Jul 2006 16:14:02 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0001uw-FA; Wed, 19 Jul 2006 15:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6JJo19R016807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jul 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3I3V-0006GQ-SA; Wed, 19 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-00.txt Pages : 19 Date : 2006-7-19 This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-syn-flood-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-syn-flood-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19143658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-syn-flood-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-syn-flood-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19143658.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Jul 19 18:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Krj-0000tW-UL; Wed, 19 Jul 2006 18:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Krj-0000tE-AZ; Wed, 19 Jul 2006 18:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Kri-0000yv-2p; Wed, 19 Jul 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6JMo1p0008479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3Krh-0000h6-QT; Wed, 19 Jul 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-03.txt Pages : 16 Date : 2006-7-19 This document specifies a new TCP option - the TCP User Timeout Option - that allows a TCP to advertise its current user timeout for a connection. Thus, the remote TCP may modify its local user timeout based on knowledge of the peer's user timeout. The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. Increasing the user timeouts allows established TCP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19150634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19150634.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Jul 19 19:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LCK-0002pb-7z; Wed, 19 Jul 2006 19:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LCJ-0002pT-1f; Wed, 19 Jul 2006 19:11:19 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3LCH-0003Oe-Gg; Wed, 19 Jul 2006 19:11:19 -0400 Received: from lars.local (host82.diegoman.hyatthsiagx.com [64.213.152.82]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AFFCE1BAC4D; Thu, 20 Jul 2006 00:56:03 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 29CB9142FC7; Wed, 19 Jul 2006 16:11:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: tsvwg@ietf.org, tcpm@ietf.org Message-Id: <6A0A885E-510F-483E-8BED-D4A16C4A94AB@netlab.nec.de> References: From: Lars Eggert Date: Wed, 19 Jul 2006 16:11:15 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [tcpm] Last Call: 'Direct Data Placement over Reliable Transports' to Proposed Standard (draft-ietf-rddp-ddp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1551942056==" Errors-To: tcpm-bounces@ietf.org --===============1551942056== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19--1050182960; protocol="application/pkcs7-signature" --Apple-Mail-19--1050182960 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, since these protocols have been discussed in TSVWG and TCPM in the past, please note that IETF LC has just started. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-02. Lars Begin forwarded message: > From: The IESG > Date: July 19, 2006 2:47:09 PM PDT > To: IETF-Announce > Cc: rddp@ietf.org > Subject: Last Call: 'Direct Data Placement over Reliable > Transports' to Proposed Standard (draft-ietf-rddp-ddp) > Reply-To: iesg@ietf.org > > The IESG has received a request from the Remote Direct Data > Placement WG to > consider the following documents: > > - 'A Remote Direct Memory Access Protocol Specification ' > as a Proposed Standard > - 'Direct Data Placement over Reliable Transports ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-02. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-rddp-rdmap-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-06.txt Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-19--1050182960 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNzE5MjMxMTE2WjAjBgkqhkiG9w0BCQQxFgQU+2t0ZjUzDdQKk2SGuxrf g2YeIOcwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAGh+0ewZwW5nAhjaKiFi1ec3rcfD+3Ro+jYL4b004N/FwM5+iV1Okk0PDo9EOvF6baAfGPHw BGUxjwERao22l+L/Y4e38T5U8Ss7R5FTZe7EsMprbGLLSTQ7SVeZmndkGISk+LsfEKRB2SFUj10E UUYpCD/DMpbSc+QbWbjLZjqKayHPqc9+9ZSe7JxcmcbMJULlfZxNzp8YQK6UN92Eb9T4kzknGr4O d1LuNJL6XA/3L60/3WEJHxPi7RTMxMPJu15LJWGoJhdQlkauOBzmSC0j4tRmEudKCa8RDM+gtf8I q+7kvfHe3vR2BhjRxUunaoOWupvYP0e9xdwCq0eAyS0AAAAAAAA= --Apple-Mail-19--1050182960-- --===============1551942056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1551942056==-- From tcpm-bounces@ietf.org Wed Jul 19 19:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LVh-0005JV-EP; Wed, 19 Jul 2006 19:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LVg-0005JQ-Da for tcpm@ietf.org; Wed, 19 Jul 2006 19:31:20 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3LVe-0005Mk-Pq for tcpm@ietf.org; Wed, 19 Jul 2006 19:31:20 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6JNTbEj013695; Wed, 19 Jul 2006 20:30:16 -0300 Message-Id: <7.0.1.0.0.20060719200945.0625ec08@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 19 Jul 2006 20:22:54 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft In-Reply-To: <44BE4C27.1010600@isi.edu> References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> <44BD7441.9050206@isi.edu> <7.0.1.0.0.20060719031923.04a637f0@gont.com.ar> <44BE4C27.1010600@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 12:13 19/07/2006, Joe Touch wrote: > > I understand what you mean. However, the message codes to which we are > > changing from hard to soft errors (protocol unreachable and port > > unreachable) are not the ones that would reflect a routing change. > >Sorry - long time since I got into this level of detail. We're talking >about dest unreachable codes 2-4, i.e.: > 2 protocol > 3 port > 4 frag needed and DF set > >Changing these from hard to soft AFTER connection establishment means: > > - slower reaction (if at all?) to host reconfiguration > 2,3 - dynamic reloading of protocol module fails Agreed in the case of protocol unreachable. But for port unreachable, the protocol module is there. > 3 - unexpected application termination (?) > although TCP can send a RST in this case, > ICMP should also generate port unreachable (?) What I recall is that the idea of making TCP abort connections upon receipt of port unreach had to do with accomodating implementation that rejected connection requests with ICMP port unreachables, rather than with RSTs. In the case of TCP, only RSTs should be sent. As a matter of fact, sending both RSTs and port unreachables could be used by an attacker as a bandwidth amplifier. >Reloading protocols isn't unheard of (netgraph, etc.). Failure of that >protocol has many consequences, and at some level nonresponsiveness is >its own signal, but softening these signals basically means you are >assuming that protocols don't change once a connection is up. That's a >NEW assumption and should be noted. Agreed. In this case, we are limiting the discussion to TCP, though. > - slower/no reaction to path change > 4 - change in path MTU IMHO, this would kill robustness. In TCP, you implement PMTUD, or don't set the DF bit. >As to the case where ICMP Frag needed should generate a hard error, >consider: > - simple TCP stack that lacks PMTUD > - an intermediate device sets the DF bit > >I saw that case a few years ago. Changing hard to soft changes reaction >to that event Well, that seems non-compliant, anyway. Also, for robustness-sake, you probably don't have many choices other than keep retransmitting. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 20 01:01:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Qen-00051J-I7; Thu, 20 Jul 2006 01:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Qem-00051D-GZ for tcpm@ietf.org; Thu, 20 Jul 2006 01:01:04 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Qel-00087K-2o for tcpm@ietf.org; Thu, 20 Jul 2006 01:01:04 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6K50BH16643; Wed, 19 Jul 2006 22:00:11 -0700 (PDT) Message-ID: <44BF0DD1.4000509@isi.edu> Date: Wed, 19 Jul 2006 22:00:01 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> <44BD7441.9050206@isi.edu> <7.0.1.0.0.20060719031923.04a637f0@gont.com.ar> <44BE4C27.1010600@isi.edu> <7.0.1.0.0.20060719200945.0625ec08@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060719200945.0625ec08@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0621059897==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0621059897== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF5E9875303CCDAD49F0F895" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF5E9875303CCDAD49F0F895 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 12:13 19/07/2006, Joe Touch wrote: >=20 >> > I understand what you mean. However, the message codes to which we a= re >> > changing from hard to soft errors (protocol unreachable and port >> > unreachable) are not the ones that would reflect a routing change. >> >> Sorry - long time since I got into this level of detail. We're talking= >> about dest unreachable codes 2-4, i.e.: >> 2 protocol >> 3 port >> 4 frag needed and DF set >> >> Changing these from hard to soft AFTER connection establishment means:= >> >> - slower reaction (if at all?) to host reconfiguration >> 2,3 - dynamic reloading of protocol module fails >=20 > Agreed in the case of protocol unreachable. But for port unreachable, > the protocol module is there. That depends on what protocol; port unreachable would happen for the application protocol failure. >> 3 - unexpected application termination (?) >> although TCP can send a RST in this case, >> ICMP should also generate port unreachable (?)= >=20 > What I recall is that the idea of making TCP abort connections upon > receipt of port unreach had to do with accomodating implementation that= > rejected connection requests with ICMP port unreachables, rather than > with RSTs. >=20 > In the case of TCP, only RSTs should be sent. As a matter of fact, > sending both RSTs and port unreachables could be used by an attacker as= > a bandwidth amplifier. 1122 allows both. It makes specific statements that the RST isn't a replacement for the ICMP. It might be OK to say that if a RST is generated then the ICMP shouldn't be, but that'd be in an 1122 'host-wide' document, not in an ICMP document (which shouldn't discuss snooping the TCP segments). You're implying that ICMP port unreachable should never be sent when there is a functioning TCP (i.e., protocol unreachable is OK, but never port) - and THAT is your rationale for treating them as soft errors. If that's the case, then they should be silently dropped, and you are REALLY changing 1122. >> Reloading protocols isn't unheard of (netgraph, etc.). Failure of that= >> protocol has many consequences, and at some level nonresponsiveness is= >> its own signal, but softening these signals basically means you are >> assuming that protocols don't change once a connection is up. That's a= >> NEW assumption and should be noted. >=20 > Agreed. In this case, we are limiting the discussion to TCP, though. I was talking about TCP - e.g., loading a new implementation of TCP. >> - slower/no reaction to path change >> 4 - change in path MTU >=20 > IMHO, this would kill robustness. In TCP, you implement PMTUD, or don't= > set the DF bit. Or you expect the connection to go down because of the specified behavior of ICMP. That might allow a host to try a different path, different endpoint, etc. more quickly. >> As to the case where ICMP Frag needed should generate a hard error, >> consider: >> - simple TCP stack that lacks PMTUD >> - an intermediate device sets the DF bit >> >> I saw that case a few years ago. Changing hard to soft changes reactio= n >> to that event >=20 > Well, that seems non-compliant, anyway. Based on what? I could find nothing that prohibits a node from setting the DF bit - that could occur when fragmentation is not desired (fate sharing over wireless links, e.g.) even though the end system can support it. > Also, for robustness-sake, you > probably don't have many choices other than keep retransmitting. That's what happens due to your proposed modification. If these errors are still hard, then the connection goes down and you can recover at the application layer by trying a different endpoint, different parameters, etc. - something that might change the path properties. Joe --------------enigDF5E9875303CCDAD49F0F895 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvw3VE5f5cImnZrsRAojdAKDNzGJCFskMvpx6Z6wE3hkiTstZ7QCeKJ12 IXivZUa9GixkhYAWZgKv784= =U4gs -----END PGP SIGNATURE----- --------------enigDF5E9875303CCDAD49F0F895-- --===============0621059897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0621059897==-- From tcpm-bounces@ietf.org Thu Jul 20 09:00:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Y8p-0001Ej-Dm; Thu, 20 Jul 2006 09:00:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Y8n-0001Ea-EM; Thu, 20 Jul 2006 09:00:33 -0400 Received: from mga06.intel.com ([134.134.136.21] helo=orsmga101.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Y8l-0005Lt-W9; Thu, 20 Jul 2006 09:00:33 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 20 Jul 2006 06:00:30 -0700 Received: from azsmsx334.amr.corp.intel.com ([10.2.121.57]) by orsmga001.jf.intel.com with ESMTP; 20 Jul 2006 05:55:41 -0700 X-IronPort-AV: i="4.07,161,1151910000"; d="txt'208?scan'208,208"; a="68065525:sNHT6213488918" Received: from azsmsx331.amr.corp.intel.com ([10.2.161.41]) by azsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 05:55:23 -0700 Received: from mail pickup service by azsmsx331.amr.corp.intel.com with Microsoft SMTPSVC; Thu, 20 Jul 2006 05:55:10 -0700 Received: from azsmsx333.amr.corp.intel.com ([10.2.121.77]) by azsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:59:13 -0700 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:57:37 -0700 Received: from azsmga101.ch.intel.com ([10.2.16.36]) by azsmga001.ch.intel.com with ESMTP; 19 Jul 2006 15:51:25 -0700 Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by azsmga101.ch.intel.com with ESMTP; 19 Jul 2006 15:51:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,261,1149490800"; d="txt'208?scan'208,208"; a="89700441:sNHT32498137" Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Krm-0000vf-OJ; Wed, 19 Jul 2006 18:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Krj-0000tE-AZ; Wed, 19 Jul 2006 18:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Kri-0000yv-2p; Wed, 19 Jul 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6JMo1p0008479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3Krh-0000h6-QT; Wed, 19 Jul 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 18:50:01 -0400 X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-OriginalArrivalTime: 19 Jul 2006 22:57:37.0288 (UTC) FILETIME=[BAB2B880:01C6AB86] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt X-BeenThere: tcpm@ietf.org Reply-To: internet-drafts@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-03.txt Pages : 16 Date : 2006-7-19 This document specifies a new TCP option - the TCP User Timeout Option - that allows a TCP to advertise its current user timeout for a connection. Thus, the remote TCP may modify its local user timeout based on knowledge of the peer's user timeout. The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. Increasing the user timeouts allows established TCP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19150634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19150634.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Thu Jul 20 15:47:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eUV-0000Ec-A4; Thu, 20 Jul 2006 15:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eUT-0000CC-Q6 for tcpm@ietf.org; Thu, 20 Jul 2006 15:47:21 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3eUS-0008C1-F7 for tcpm@ietf.org; Thu, 20 Jul 2006 15:47:21 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id A33E6C29E for ; Thu, 20 Jul 2006 15:47:19 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6KJlJ5U006181 for ; Thu, 20 Jul 2006 15:47:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6KJlIVP022663 for ; Thu, 20 Jul 2006 15:47:19 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 18291-28 for ;Thu, 20 Jul 2006 15:47:12 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6KJlBOM022575for ; Thu, 20 Jul 2006 15:47:11 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 5A5624FCE4; Thu, 20 Jul 2006 15:47:34 -0400 (EDT) Date: Thu, 20 Jul 2006 15:47:34 -0400 From: Wesley Eddy To: tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-00.txt Message-ID: <20060720194734.GC3239@grc.nasa.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.040 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, Jul 19, 2006 at 03:50:01PM -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP SYN Flooding Attacks and Common Mitigations > Author(s) : W. Eddy > Filename : draft-ietf-tcpm-syn-flood-00.txt > Pages : 19 > Date : 2006-7-19 > > This document describes TCP SYN flooding attacks, which have been > well-known to the community for several years. Various > countermeasures against these attacks, and the trade-offs of each, > are described. This document archives explanations of the attack and > common defense techniques for the benefit of TCP implementers and > administrators of TCP servers or networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-00.txt > As discussed in Montreal, we are looking for comments from people who have implemented or used the defense mechanisms discussed in this draft. The draft includes some data on specific implementations, which I believe are accurate, but I strongly encourage people associated with vendors or open-source projects to verify this, or help augment the content. There are a couple of major operating systems that are not currently discussed. We also would be interested in input from operators as to which defenses are commonly turned on/off. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 20 16:39:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIr-00070G-3F; Thu, 20 Jul 2006 16:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIq-0006zc-3j for tcpm@ietf.org; Thu, 20 Jul 2006 16:39:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fGH-0006rT-Eh for tcpm@ietf.org; Thu, 20 Jul 2006 16:36:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2006 13:36:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KKaiKV012656 for ; Thu, 20 Jul 2006 13:36:44 -0700 Received: from [10.34.37.171] ([10.34.37.171]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6KKaiiB028060 for ; Thu, 20 Jul 2006 13:36:44 -0700 (PDT) Message-ID: <44BFE95C.4070001@cisco.com> Date: Thu, 20 Jul 2006 13:36:44 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/mixed; boundary="------------000305060203090201000403" DKIM-Signature: a=rsa-sha1; q=dns; l=1862; t=1153427804; x=1154291804; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:Mahesh=20Jethanandani=20 |Subject:TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DqwKLOoM9ZzqT/XvePVQWCYS22Vg=3D; b=k7kI1DxO/O3IOL7LnsDsAV+01Suad06Vh3A2lPiNwWYD3GkZlHp9eOPFIHd/rACjWMOezzCA I/rsfR1qubUW4fv8byGUC/Lon7PvcjRzA97IIhmMmipbzLTReIitreG7; Authentication-Results: sj-dkim-2.cisco.com; header.From=mahesh@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [tcpm] TCP zero window timeout? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------000305060203090201000403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We recently ran into a customer case where the client was advertising a zero window towards our TCP stack in the middle of a stream. Subsequent probes were also resulting in a zero window advertisement. While it was clear that the client application was where the problem was, our TCP implementation was left holding a lot of client data (we are a proxy). The result was that we ultimately ran out of buffers and stopped processing new connections. This was a problem for our customer also and they were looking for a solution. So we decided to offer a fix in the form of TCP option that the customer could configure. The fix entailed using the idle timeout period and the normal persist backoff mechanism to determine if the client had made any progress (towards opening up the window), and if it had not, we would time out the connection with a RST, and reclaim all the buffers. Would this be considered reasonable to make the server robust? Is there a RFC that talks about it? If not, would it be of interest to this group for me to write a draft, describing the changes we made? --------------000305060203090201000403 Content-Type: text/x-vcard; charset=utf-8; name="mahesh.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mahesh.vcf" begin:vcard fn:Mahesh Jethanandani n:Jethanandani;Mahesh org:Cisco Systems Inc.;ADBU adr:;;170 West Tasman Drive;San Jose;CA;95134;United States of America email;internet:mahesh@cisco.com title:Technical Leader tel;work:408 527-8230 tel;fax:408 527-0147 tel;pager:408 308-6353 tel;cell:408 761-9683 url:http://www.cisco.com version:2.1 end:vcard --------------000305060203090201000403 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------000305060203090201000403-- From tcpm-bounces@ietf.org Fri Jul 21 12:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3xvH-00058o-3o; Fri, 21 Jul 2006 12:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3xvE-000567-ES for tcpm@ietf.org; Fri, 21 Jul 2006 12:32:16 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3xnZ-0003ih-3y for tcpm@ietf.org; Fri, 21 Jul 2006 12:24:24 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.6/8.13.0) with ESMTP id k6LGOJbF022051 for ; Fri, 21 Jul 2006 09:24:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] TCP zero window timeout? Date: Fri, 21 Jul 2006 09:24:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP zero window timeout? Thread-Index: Acas3smHvUvz1eaCTge7psQ7U08oQgAAtvVw From: "Mahdavi, Jamshid" To: X-Scanned-By: MIMEDefang 2.55 on 216.52.23.28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org What is the status of draft-eggert-tcpm-tcp-abort-timeout-option-01? It may be of some use in situations like this. I've recently seen another scenario where this would be useful, so I'd be interested in seeing that draft reposted... --Jamshid _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jul 22 14:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4LoS-0007JU-Lz; Sat, 22 Jul 2006 14:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4LoR-0007JO-6r for tcpm@ietf.org; Sat, 22 Jul 2006 14:02:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4LoP-0002xJ-Ti for tcpm@ietf.org; Sat, 22 Jul 2006 14:02:51 -0400 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6MI2nl5027538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Jul 2006 14:02:49 -0400 (EDT) Received: from dynasty.cs.columbia.edu (localhost [127.0.0.1]) by dynasty.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6MI2nE6003395; Sat, 22 Jul 2006 14:02:49 -0400 (EDT) Received: from localhost (salman@localhost) by dynasty.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id k6MI2hV9003392; Sat, 22 Jul 2006 14:02:43 -0400 (EDT) X-Authentication-Warning: dynasty.cs.columbia.edu: salman owned process doing -bs Date: Sat, 22 Jul 2006 14:02:43 -0400 (EDT) From: Salman Abdul Baset To: tcpm@ietf.org, end2end-interest@postel.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [tcpm] rfc2581bis-01 and RFC 2861 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org (Note: This post is being sent to tcpm and end2end-interest mailing lists) The issue is that RFC 2861 (Experimental) suggests to cap cwnd if application is rate limited. For example, for sending CBR over TCP with RTT of 100ms and CBR rate of 10ms, the cwnd should not theoretically increase beyond 11. The latest TCP congestion control draft: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-01.txt does not allude to RFC 2861. This latest draft perhaps tries to combine the RFC 2581 (TCP Congestion Control) and RFC 3465 (Appropriate Byte Couting) in one document. In $3.1, (page 5, par 5) it suggests: "The RECOMMENDED way to increase cwnd during congestion avoidance is to count the number of bytes that have been acknowledged by ACKs for new data. (A drawback of this implementation is that it requires maintaining an additional state variable.) When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS bytes. Note that during congestion avoidance, cwnd MUST NOT be increased by more than SMSS bytes per RTT. This method both allows TCPs to increase cwnd by one segment per RTT in the face of delayed ACKs and provides robustness against ACK Division attacks." It clearly states that cwnd should be increased if number of bytes in current cwnd have been acknowledged. This implies that cwnd increase will also happen for CBR traffic, albeit at a slower rate because of application rate limitation. I am not sure if it is an intentional omission by the authors but this seems to have significant implications for sending CBR over TCP. For example, delays incurred by CBR stream can be quite different because of cwnd limitation (due to application rate). Regards, Salman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jul 22 16:45:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4OLd-0002rM-0O; Sat, 22 Jul 2006 16:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4OLb-0002rH-9z for tcpm@ietf.org; Sat, 22 Jul 2006 16:45:15 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4OLZ-0001ro-L9 for tcpm@ietf.org; Sat, 22 Jul 2006 16:45:15 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k6MKilso009017; Sat, 22 Jul 2006 17:44:49 -0300 Message-Id: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 22 Jul 2006 17:11:22 -0300 To: "Mahdavi, Jamshid" , From: Fernando Gont Subject: RE: [tcpm] TCP zero window timeout? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:24 21/07/2006, Mahdavi, Jamshid wrote: >What is the status of draft-eggert-tcpm-tcp-abort-timeout-option-01? It >may be of some use in situations like this. I've recently seen another >scenario where this would be useful, so I'd be interested in seeing that >draft reposted... It was merged with draft-gont-tcpm-tcp-auto-option into draft-ietf-tcpm-tcp-uto. The latest revision is draft-ietf-tcpm-tcp-uto-03.txt, available at the usual places (e.g., http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt). Feedback is more than welcome. ;-) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Jul 23 22:07:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4pr9-0000ai-Cd; Sun, 23 Jul 2006 22:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4pr7-0000Sg-Mu for tcpm@ietf.org; Sun, 23 Jul 2006 22:07:37 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4pr6-0006YE-92 for tcpm@ietf.org; Sun, 23 Jul 2006 22:07:37 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6O27T13090915; Sun, 23 Jul 2006 19:07:29 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 51B7677ACAD; Sun, 23 Jul 2006 22:07:27 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A7B6D441017; Sun, 23 Jul 2006 22:06:15 -0400 (EDT) To: Salman Abdul Baset From: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: In the City MIME-Version: 1.0 Date: Sun, 23 Jul 2006 22:06:15 -0400 Message-Id: <20060724020615.A7B6D441017@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560743198==" Errors-To: tcpm-bounces@ietf.org --===============1560743198== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > (Note: This post is being sent to tcpm and end2end-interest mailing > lists) I have cut end2end off this reply as this seems to be a WG matter and we probably do not need to clutter e2e. > The latest TCP congestion control draft: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-01.txt > > does not allude to RFC 2861. This latest draft perhaps tries to > combine the RFC 2581 (TCP Congestion Control) and RFC 3465 > (Appropriate Byte Couting) in one document. This is incorrect. The goal of the above listed I-D is to fix problems with the current congestion control *specification* (not algorithmic problems). And, further to roll in a couple of quite minor *standards track* extensions to TCP (namely a larger initial cwnd (RFC 3390) and limited transmit (RFC 3042). We explicitly *do not* roll in Appropriate Byte Counting (RFC 3465) because, as you note, it is not a standards track extension at this time. > In $3.1, (page 5, par 5) it suggests: > > "The RECOMMENDED way to increase cwnd during congestion avoidance is > to count the number of bytes that have been acknowledged by ACKs for > new data. (A drawback of this implementation is that it requires > maintaining an additional state variable.) When the number of bytes > acknowledged reaches cwnd, then cwnd can be incremented by up to > SMSS bytes. Note that during congestion avoidance, cwnd MUST NOT be > increased by more than SMSS bytes per RTT. This method both allows > TCPs to increase cwnd by one segment per RTT in the face of delayed > ACKs and provides robustness against ACK Division attacks." Note that this is only a slight change from RFC 2581 and the above is *not* ABC. First, ABC is about how to increase cwnd during *slow start* while the above paragraph discusses congestion avoidance. Second, the byte counting method for increasing cwnd during congestion avoidance is specifically allowed in RFC 2581. The change is that it is RECOMMENDED in the latest draft. (The change is an attempt to mitigate a security problem with receiver's ACKing each byte in a packet separately to try to artificially inflate the sender's cwnd.) > I am not sure if it is an intentional omission by the authors but this > seems to have significant implications for sending CBR over TCP. For > example, delays incurred by CBR stream can be quite different because > of cwnd limitation (due to application rate). I do not follow the problem you are getting at here. If you traffic is CBR and you have enough cwnd to send at that CBR then why would increasing it beyond what will provide the given rate impact the traffic? I just can't see the point you're trying to make here, can you try again? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFExCsXWyrrWs4yIs4RAgTXAKCBIwk+MLxoZ/ZdlcLW+a1CcR/wwwCdH+eq y/odP93brgeaPqJgj+8AfJ8= =i11j -----END PGP SIGNATURE----- --=_bOundary-- --===============1560743198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1560743198==-- From tcpm-bounces@ietf.org Mon Jul 24 03:11:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ub6-0008R6-1V; Mon, 24 Jul 2006 03:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ub4-0008R0-GT for tcpm@ietf.org; Mon, 24 Jul 2006 03:11:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4t1p-0003zY-ER for tcpm@ietf.org; Mon, 24 Jul 2006 01:30:53 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G4sp8-0005vP-1P for tcpm@ietf.org; Mon, 24 Jul 2006 01:17:52 -0400 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6O5Hgl5020777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jul 2006 01:17:42 -0400 (EDT) Received: from dynasty.cs.columbia.edu (localhost [127.0.0.1]) by dynasty.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6O5HXE6006024; Mon, 24 Jul 2006 01:17:42 -0400 (EDT) Received: from localhost (salman@localhost) by dynasty.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id k6O5HIuZ006018; Mon, 24 Jul 2006 01:17:28 -0400 (EDT) X-Authentication-Warning: dynasty.cs.columbia.edu: salman owned process doing -bs Date: Mon, 24 Jul 2006 01:17:17 -0400 (EDT) From: Salman Abdul Baset To: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: <20060724020615.A7B6D441017@lawyers.icir.org> Message-ID: References: <20060724020615.A7B6D441017@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > > The latest TCP congestion control draft: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-01.txt > > > > does not allude to RFC 2861. This latest draft perhaps tries to > > combine the RFC 2581 (TCP Congestion Control) and RFC 3465 > > (Appropriate Byte Couting) in one document. > > This is incorrect. The goal of the above listed I-D is to fix problems > with the current congestion control *specification* (not algorithmic > problems). And, further to roll in a couple of quite minor *standards > track* extensions to TCP (namely a larger initial cwnd (RFC 3390) and > limited transmit (RFC 3042). True. I guess the question is when/if RFC 2861 will be incorporated as a Standards track rfc. As you are probably aware, Linux 2.4 and onwards implement 2861. Ofcourse, this is not the reason for making an experimental RFC a standard but I was hoping to find some effort towards it. Perhaps, there is one but I have not scanned all the archives. Also, such an effort is not evident from the WG description and 'Goals and Milestones'. > I do not follow the problem you are getting at here. If you traffic is > CBR and you have enough cwnd to send at that CBR then why would > increasing it beyond what will provide the given rate impact the > traffic? I just can't see the point you're trying to make here, can you > try again? So I guess, there are two ways of increasing cwnd during CA. One is to increase the window based on number of ACKs received (which is what Linux is doing and eq (2) in RFC 2581) and the other is to increase it based on number of bytes ACKed (2581: page 5, par 3). It appears that RFC 2581 recommends both. As you mentioned, the new draft recommends the later. Now consider CBR over TCP. The window will increase quickly for the first case assuming packets are smaller than MSS (100 byte packet and 1448 byte MSS). It will increase slowly for the second case. For a MSS of 200 bytes and packet size of 100 bytes, the cwnd increase rate is 1/2 of the first case. When there is a TDACK loss, cwnd will be reduced to half. The CBR over TCP traffic is not impacted if after a loss cwnd is big enough to maintain the rate. Now consider RFC 2861. It says that cap the cwnd if application is rate-limited. For a CBR rate of 100 packet/s (or every 10ms) and RTT of 100ms, the cwnd should not theoretically increase beyond 11 because the number of packets inflight are 10. In practice, it increases to a higher value (and stays there if there is no loss) because the packets are buffered when cwnd < CBR rate. A CBR over a TCP implementation that follows RFC 2861 is more likely to suffer from cwnd limited delays than a TCP implementation that keeps increasing cwnd. Similarly, CBR over TCP also benefits from not doing byte counting during slow start and CA. Another interesting nuance is if cwnd is significantly higher than the current traffic rate, shall it be slowly brought down? This phenomena is different from the idle period reduction. What do you think? Regards, Salman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 24 07:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yko-0006aR-9T; Mon, 24 Jul 2006 07:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ykn-0006aL-7h for tcpm@ietf.org; Mon, 24 Jul 2006 07:37:41 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4ykl-0007Tb-RG for tcpm@ietf.org; Mon, 24 Jul 2006 07:37:41 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6OBbafT005688; Mon, 24 Jul 2006 04:37:37 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id E159877B3AB; Mon, 24 Jul 2006 07:37:35 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EA6A14410F4; Mon, 24 Jul 2006 07:36:22 -0400 (EDT) To: Salman Abdul Baset From: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: In the City MIME-Version: 1.0 Date: Mon, 24 Jul 2006 07:36:22 -0400 Message-Id: <20060724113622.EA6A14410F4@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1726404289==" Errors-To: tcpm-bounces@ietf.org --===============1726404289== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline There are a lot of disparate things in your email. Let's see ... > True. I guess the question is when/if RFC 2861 will be incorporated as > a Standards track rfc. As you are probably aware, Linux 2.4 and > onwards implement 2861. Ofcourse, this is not the reason for making an > experimental RFC a standard but I was hoping to find some effort > towards it. Perhaps, there is one but I have not scanned all the > archives. Also, such an effort is not evident from the WG description > and 'Goals and Milestones'. With my WG chair hat on .... This WG certainly can be a forum for advancing specs (e.g., from Experimental to PS). That general notion is in the charter and if someone wanted to bring forth the energy to consider the advancing of RFC2861 I think that'd be fine for the WG to consider. Enough with the hat. > So I guess, there are two ways of increasing cwnd during CA. One is to > increase the window based on number of ACKs received (which is what > Linux is doing and eq (2) in RFC 2581) and the other is to increase it > based on number of bytes ACKed (2581: page 5, par 3). It appears that > RFC 2581 recommends both. As you mentioned, the new draft recommends > the later. The draft (and RFC 2581) *allows* both and the draft *recommends* byte counting during CA. > Now consider CBR over TCP. The window will increase quickly for the > first case assuming packets are smaller than MSS (100 byte packet and > 1448 byte MSS). It will increase slowly for the second case. For a MSS > of 200 bytes and packet size of 100 bytes, the cwnd increase rate is > 1/2 of the first case. Yes. One could argue that the faster increase (the traditional approach) is inappropriate, but it is a pretty small effect (and, it can cut both ways---sometimes being beneficial and sometimes not). > When there is a TDACK loss, cwnd will be reduced to half. The CBR over > TCP traffic is not impacted if after a loss cwnd is big enough to > maintain the rate. RFC 2581 bases the reduction of cwnd on FlightSize (amount of outstanding data) not cwnd. So, the CBR over TCP will be reduced by half. I.e., if you have 10 packets outstanding, a cwnd of 100000 packets and take a loss your new cwnd should be 5 packets. The notion of FlightSize was introduced into the spec. to accommodate cases whereby the cwnd does not accurately reflect the load being placed on the path. (As has been discussed on this list before, this is not an ideal fix because it causes issues in another case.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFExLC2WyrrWs4yIs4RArkWAJwJhX2s5yu2WAEc5pgGXv/nF9dYlACfTVZt VeelMc4VmF6OZBNeXCuv/Lc= =D9YJ -----END PGP SIGNATURE----- --=_bOundary-- --===============1726404289== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1726404289==-- From tcpm-bounces@ietf.org Mon Jul 24 12:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53P6-0004BT-Ud; Mon, 24 Jul 2006 12:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53P5-00043W-Av for tcpm@ietf.org; Mon, 24 Jul 2006 12:35:35 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G53P4-0000V4-0M for tcpm@ietf.org; Mon, 24 Jul 2006 12:35:35 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 09:35:33 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 09:35:33 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 09:35:31 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Mon, 24 Jul 2006 09:35:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] rfc2581bis-01 and RFC 2861 Date: Mon, 24 Jul 2006 09:35:18 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064015DE074@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <20060724113622.EA6A14410F4@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] rfc2581bis-01 and RFC 2861 Thread-Index: AcavFaCEDyA7RjiSS0a7ofAeO0ej7AAKPP3w References: <20060724113622.EA6A14410F4@lawyers.icir.org> From: "Christian Huitema" To: , "Salman Abdul Baset" X-OriginalArrivalTime: 24 Jul 2006 16:35:20.0313 (UTC) FILETIME=[2742D690:01C6AF3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > RFC 2581 bases the reduction of cwnd on FlightSize (amount of > outstanding data) not cwnd. So, the CBR over TCP will be reduced by > half. I.e., if you have 10 packets outstanding, a cwnd of 100000 > packets and take a loss your new cwnd should be 5 packets. The notion > of FlightSize was introduced into the spec. to accommodate cases > whereby the cwnd does not accurately reflect the load being placed on > the path. > (As has been discussed on this list before, this is not an ideal fix > because it causes issues in another case.) One may in fact question whether this is even the right thing. Suppose a 1 Mbps link is shared between a 64 kpbs "CBR" flow and a "best effort" file transfer. The file transfer window will increase until it reaches something larger than 1 Mbps. A that point, queues will build up, and eventually some packets will be dropped. You certainly want the file transfer rate to drop to 512 kbps, and then progressively increase. But do you really want the CBR flow to drop to 32 kbps? Is that fair? Is that even useful? -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 24 12:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53eX-0002Nr-5h; Mon, 24 Jul 2006 12:51:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53eV-0002JX-Ur for tcpm@ietf.org; Mon, 24 Jul 2006 12:51:31 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G53eT-0001VI-NC for tcpm@ietf.org; Mon, 24 Jul 2006 12:51:31 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6OGpSl5024363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jul 2006 12:51:28 -0400 (EDT) Received: from play.cs.columbia.edu (localhost [127.0.0.1]) by play.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6OGpSXD013479; Mon, 24 Jul 2006 12:51:28 -0400 (EDT) Received: from localhost (salman@localhost) by play.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id k6OGpKBa013475; Mon, 24 Jul 2006 12:51:20 -0400 (EDT) X-Authentication-Warning: play.cs.columbia.edu: salman owned process doing -bs Date: Mon, 24 Jul 2006 12:51:20 -0400 (EDT) From: Salman Abdul Baset To: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: <20060724113622.EA6A14410F4@lawyers.icir.org> Message-ID: References: <20060724113622.EA6A14410F4@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Thanks a lot for your comments. My comments inline. > The draft (and RFC 2581) *allows* both and the draft *recommends* byte > counting during CA. True. I actually meant that but you put it the right way. > > Now consider CBR over TCP. The window will increase quickly for the > > first case assuming packets are smaller than MSS (100 byte packet and > > 1448 byte MSS). It will increase slowly for the second case. For a MSS > > of 200 bytes and packet size of 100 bytes, the cwnd increase rate is > > 1/2 of the first case. > > Yes. One could argue that the faster increase (the traditional > approach) is inappropriate, but it is a pretty small effect (and, it can > cut both ways---sometimes being beneficial and sometimes not). Can you elaborate how it may not be beneficial? > RFC 2581 bases the reduction of cwnd on FlightSize (amount of > outstanding data) not cwnd. So, the CBR over TCP will be reduced by > half. I.e., if you have 10 packets outstanding, a cwnd of 100000 > packets and take a loss your new cwnd should be 5 packets. The notion > of FlightSize was introduced into the spec. to accommodate cases whereby > the cwnd does not accurately reflect the load being placed on the path. > (As has been discussed on this list before, this is not an ideal fix > because it causes issues in another case.) You are right. However, as Christian Huitema pointed out, there are fairness issues here. Somewhere, I read about sharing information between different TCP connections. That might be useful in this scenario to maintain fairness. So an application like Skype when forced to send voice over a TCP implementation (assuming UDP is blocked) which: 1) does ACK counting during CA May increase the packet rate to increase the inflight packets to mitigate the cwnd=ssthresh=(flightsize/2) 2) byte counting during CA May increase the packet rate and voice packet size to MSS to mitigate the cwnd decrease. Regards, Salman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 24 12:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53fO-0002wn-Me; Mon, 24 Jul 2006 12:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53fM-0002wi-UE for tcpm@ietf.org; Mon, 24 Jul 2006 12:52:24 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G53fL-0001Zl-HJ for tcpm@ietf.org; Mon, 24 Jul 2006 12:52:24 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6OGqGsv014577; Mon, 24 Jul 2006 09:52:16 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 684A577B3AB; Mon, 24 Jul 2006 12:52:15 -0400 (EDT) To: "Christian Huitema" From: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064015DE074@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lift Me Up MIME-Version: 1.0 Date: Mon, 24 Jul 2006 12:52:15 -0400 Message-Id: <20060724165215.684A577B3AB@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2018906725==" Errors-To: tcpm-bounces@ietf.org --===============2018906725== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > > RFC 2581 bases the reduction of cwnd on FlightSize (amount of > > outstanding data) not cwnd. So, the CBR over TCP will be reduced by > > half. I.e., if you have 10 packets outstanding, a cwnd of 100000 > > packets and take a loss your new cwnd should be 5 packets. The > > notion of FlightSize was introduced into the spec. to accommodate > > cases whereby the cwnd does not accurately reflect the load being > > placed on the path. (As has been discussed on this list before, > > this is not an ideal fix because it causes issues in another case.) > > One may in fact question whether this is even the right thing. Certainly one could ask that question in general. But, in the context of the current discussion I don't know why one would. My scenario above is: 10 packets outstanding + cwnd=100000 packets + one packet loss, which yields a cwnd of 5 packets (per RFC 2581) Salman's note suggests: 10 packets outstanding + cwnd=10 packets (because of CWV) + one packet loss, which yields a cwnd of 5 packets (per RFC 2581) I.e., both these cases yield the same thing---an appropriate reduction of cwnd in the face inferred congestion. I don't see how to really solve this problem you note in an endpoint transport protocol without help from the congested point in the network. One would hope that some smart AQM could drop in proportion to the capacity a particular flow is using. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFExPq/WyrrWs4yIs4RAj9PAJ4vnjBAHl6DXgmODQNzUBf0qJ88sACfXXTd eyaFUDWFJW97RAv+ZbzPQNI= =9MGG -----END PGP SIGNATURE----- --=_bOundary-- --===============2018906725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2018906725==-- From tcpm-bounces@ietf.org Mon Jul 24 13:12:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53z5-0002rR-Dk; Mon, 24 Jul 2006 13:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53z4-0002rL-F2 for tcpm@ietf.org; Mon, 24 Jul 2006 13:12:46 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G53z2-0004fg-1V for tcpm@ietf.org; Mon, 24 Jul 2006 13:12:46 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6OHCfp2015200; Mon, 24 Jul 2006 10:12:42 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 92D4077B3AB; Mon, 24 Jul 2006 13:12:40 -0400 (EDT) To: Salman Abdul Baset From: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lift Me Up MIME-Version: 1.0 Date: Mon, 24 Jul 2006 13:12:40 -0400 Message-Id: <20060724171240.92D4077B3AB@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1420187143==" Errors-To: tcpm-bounces@ietf.org --===============1420187143== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > > Yes. One could argue that the faster increase (the traditional > > approach) is inappropriate, but it is a pretty small effect (and, it > > can cut both ways---sometimes being beneficial and sometimes not). > > Can you elaborate how it may not be beneficial? If you increase too fast you may cause (more) congestion. The ACK splitting attack is sort of the bounding example. If the receiver ACKs every byte then it sort of defeats congestion control. E.g., by getting the sender to increase cwnd from one packet of 1460 bytes to 1460 packets of 1460 bytes each (over 2MB) in one RTT. That sort of increase rate is not consistent with the spirit of slow start and could certainly cause congestion on the network. In congestion avoidance which way you increase things really doesn't matter as much because the increase is linear and while ACKing every byte still might help, it is probably not going to cause a big problem. > You are right. However, as Christian Huitema pointed out, there are > fairness issues here. See my response. Fairness depends on what you are competing with. Christian's example is a fine example of inequity. But, how does an endhost tell the difference between his scenario and a scenario whereby a zillion flows are all sending at 10 packets/second and therefore when there is loss the flow in question ought to be throttled? No amount of counting of bytes or using CWV of cwnd vs. FlightSize is going to give the flow the information to make the right decision. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFExP+IWyrrWs4yIs4RAqCwAJ4zVNVNfw48aq/JRi4NZ3Fc9Y9drwCghWmr JxZLYWhvk78n5F7qeMvmgMo= =1j7A -----END PGP SIGNATURE----- --=_bOundary-- --===============1420187143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1420187143==-- From tcpm-bounces@ietf.org Mon Jul 24 14:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55aq-0001qM-7z; Mon, 24 Jul 2006 14:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55ap-0001pW-BN for tcpm@ietf.org; Mon, 24 Jul 2006 14:55:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G55an-0002yW-3H for tcpm@ietf.org; Mon, 24 Jul 2006 14:55:51 -0400 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6OItc4F005045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jul 2006 14:55:43 -0400 (EDT) Received: from dynasty.cs.columbia.edu (localhost [127.0.0.1]) by dynasty.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6OItXE6015756; Mon, 24 Jul 2006 14:55:38 -0400 (EDT) Received: from localhost (salman@localhost) by dynasty.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id k6OItSbn015753; Mon, 24 Jul 2006 14:55:28 -0400 (EDT) X-Authentication-Warning: dynasty.cs.columbia.edu: salman owned process doing -bs Date: Mon, 24 Jul 2006 14:55:28 -0400 (EDT) From: Salman Abdul Baset To: Mark Allman Subject: Re: [tcpm] rfc2581bis-01 and RFC 2861 In-Reply-To: <20060724171240.92D4077B3AB@guns.icir.org> Message-ID: References: <20060724171240.92D4077B3AB@guns.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.24.111932 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > > > Yes. One could argue that the faster increase (the traditional > > > approach) is inappropriate, but it is a pretty small effect (and, it > > > can cut both ways---sometimes being beneficial and sometimes not). > > > > Can you elaborate how it may not be beneficial? > > If you increase too fast you may cause (more) congestion. Perhaps, it should not have a large (or perhaps even a small) effect on congestion because the application is CBR over TCP i.e. the application is rate-limited. For voice, the max rate is 32 kb/s (one way) or less. > In congestion avoidance which way you increase things really doesn't > matter as much because the increase is linear and while ACKing every > byte still might help, it is probably not going to cause a big problem. In the ACK counting case for increasing cwnd, the question is whether ACKing every byte will increase the cwnd quickly enough to minimize the sender incurred delay due to cwnd limitation for a CBR over TCP flow. > Fairness depends on what you are competing with. Christian's example is > a fine example of inequity. But, how does an endhost tell the > difference between his scenario and a scenario whereby a zillion flows > are all sending at 10 packets/second and therefore when there is loss > the flow in question ought to be throttled? No amount of counting of > bytes or using CWV of cwnd vs. FlightSize is going to give the flow the > information to make the right decision. True. An endhost cannot tell the difference between the scenarios you mentioned. I think an interesting question is how two flows, one FTP and one CBR over TCP originating from the same host and destined for the same host (src!=dest) compete for bandwidth. My guess is that eventually, FTP flow will eat into the bandwidth of CBR over TCP flow. I can probably check that for a FTP flow competing with a Skype voice over TCP flow in a controlled environment. Generalizing further, how large FTP-like TCP flows have an impact on small application bandwidth/rate limited TCP flows. I have not completely scanned the literature to comment if anyone has already analyzed it. Regards, Salman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 31 07:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7WGQ-0003rp-J1; Mon, 31 Jul 2006 07:48:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7WGP-0003re-AS for tcpm@ietf.org; Mon, 31 Jul 2006 07:48:49 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7WGN-0004kf-TA for tcpm@ietf.org; Mon, 31 Jul 2006 07:48:49 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6VBmiO1057382 for ; Mon, 31 Jul 2006 04:48:44 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 9C6A677AC21 for ; Mon, 31 Jul 2006 07:48:43 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4E9524453E7 for ; Mon, 31 Jul 2006 07:47:29 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Glory Days MIME-Version: 1.0 Date: Mon, 31 Jul 2006 07:47:29 -0400 Message-Id: <20060731114729.4E9524453E7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [tcpm] revising 2581: setting ssthresh on RTOs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098177511==" Errors-To: tcpm-bounces@ietf.org --===============1098177511== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- We have talked about setting ssthresh after RTOs on this list a number of times and we talked about it in Montreal. I'd like to verify what seemed the general mood in Montreal here on the list. I think this is the last bit we need to work out on 2581bis. If you have something else that you think needs done to the document, please yell. RFC 2581 says that on each RTO a TCP reduces ssthresh to FlightSize / 2. Consider a lost retransmit. Say we RTO on segment X, cut ssthresh to Y segments (Y > 2 - just for the example), cwnd becomes 1 segment and the RTO is backed off. Now, say we RTO on segment X again. The cwnd will stay at one, but the FlightSize is now 1 and so ssthresh takes its minimum value of 2 segments. The observation is that this forces linear growth for a potentially long time if this loss hiccup was caused by some small network issue like a handoff. In that case, it'd be nice to be able to keep ssthresh higher and use slow start when packets started flowing again. Also, as a practical matter I don't think the above scenario is the way we intended things to work. Rather, I think we envisioned (but, alas, did not write) suggestion #1: Suggestion #1: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment halve ssthresh (ssthresh =/ 2). Basically, this slowly degrades ssthresh as the RTO gets backed off, such that the longer TCP has been transmitting into a lousy network the less the TCP gets to use exponential increase when packets start flowing again. In addition, another variant has been suggested in the meantime, ... Suggestion #2: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment do not adjust ssthresh at all. This variant means that a TCP always gets to re-probe with slow start based on the pre-loss conditions no matter how long it took to fix the loss. Both #1 and #2 are quite safe. If the network is in a really lousy state then the TCP is going to continue to get losses even after getting out of RTO backoff without increasing the congestion window all that much. And, if that happens then ssthresh will get further reduced (probably to its minimum). Essentially, if the network is heavily loaded all of the sudden then this additional loss isn't really going to be exacerbated by the first couple RTTs of slow start. If the backoff was caused by something other than a suddenly massively congested network then this tweak lets TCP get back to a reasonable operating point more rapidly. So, a couple of questions ... and, the authors current hits ... (1) Is this change in-scope for 2581bis? We said "no algorithmic tweaks" and so one view is that this should be cooked elsewhere and rolled in later. The author's hit on this is that the behavior of slamming ssthresh down on the first backed off RTO is not our intent and so tweaking this seems in-scope. (2) Assuming folks are fine with making a change then which change should we make? Suggestion #1 or #2? The author's chatted and we feel like #2 is fine. As noted above, neither case really aggravates the state of the network in suddenly heavily loaded situations. So, #2 seems OK. What do people think? Is #2 OK? Or, something else? Thanks in advance for the feedback! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEze3QWyrrWs4yIs4RAqy7AKCAPUk8Y7VjVbY/NNzlEKgCAPS9rwCeIl52 9SitCSA3TfKXNJnc6vqrIPg= =wxZ9 -----END PGP SIGNATURE----- --=_bOundary-- --===============1098177511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1098177511==-- From tcpm-bounces@ietf.org Mon Jul 31 08:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7X8h-0007lN-Dm; Mon, 31 Jul 2006 08:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7X8g-0007lI-LT for tcpm@ietf.org; Mon, 31 Jul 2006 08:44:54 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7X8f-0002po-8M for tcpm@ietf.org; Mon, 31 Jul 2006 08:44:54 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6VCiq25015550 for ; Mon, 31 Jul 2006 05:44:52 -0700 (MST) Received: from zuk35exm63.ds.mot.com (zuk35exm63.ea.mot.com [10.178.1.42]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k6VCiqYg006530 for ; Mon, 31 Jul 2006 07:44:52 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] revising 2581: setting ssthresh on RTOs Date: Mon, 31 Jul 2006 13:44:51 +0100 Message-ID: In-Reply-To: <20060731114729.4E9524453E7@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] revising 2581: setting ssthresh on RTOs thread-index: Aca0l1ogquY8VQhkR4SnBG2PkTgU3QAB6oEg From: "Gil Jose-josegil1" To: , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I agree and support #2. Jose=20 -----Original Message----- From: Mark Allman [mailto:mallman@icir.org]=20 Sent: 31 July 2006 12:47 To: tcpm@ietf.org Subject: [tcpm] revising 2581: setting ssthresh on RTOs =20 Folks- We have talked about setting ssthresh after RTOs on this list a number of times and we talked about it in Montreal. I'd like to verify what seemed the general mood in Montreal here on the list. I think this is the last bit we need to work out on 2581bis. If you have something else that you think needs done to the document, please yell. RFC 2581 says that on each RTO a TCP reduces ssthresh to FlightSize / 2. Consider a lost retransmit. Say we RTO on segment X, cut ssthresh to Y segments (Y > 2 - just for the example), cwnd becomes 1 segment and the RTO is backed off. Now, say we RTO on segment X again. The cwnd will stay at one, but the FlightSize is now 1 and so ssthresh takes its minimum value of 2 segments. The observation is that this forces linear growth for a potentially long time if this loss hiccup was caused by some small network issue like a handoff. In that case, it'd be nice to be able to keep ssthresh higher and use slow start when packets started flowing again. Also, as a practical matter I don't think the above scenario is the way we intended things to work. Rather, I think we envisioned (but, alas, did not write) suggestion #1: Suggestion #1: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment halve ssthresh (ssthresh =3D/ 2). Basically, this slowly degrades ssthresh as the RTO gets backed off, such that the longer TCP has been transmitting into a lousy network the less the TCP gets to use exponential increase when packets start flowing again. In addition, another variant has been suggested in the meantime, ... Suggestion #2: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment do not adjust ssthresh at all. This variant means that a TCP always gets to re-probe with slow start based on the pre-loss conditions no matter how long it took to fix the loss.=20 Both #1 and #2 are quite safe. If the network is in a really lousy state then the TCP is going to continue to get losses even after getting out of RTO backoff without increasing the congestion window all that much. And, if that happens then ssthresh will get further reduced (probably to its minimum). Essentially, if the network is heavily loaded all of the sudden then this additional loss isn't really going to be exacerbated by the first couple RTTs of slow start. If the backoff was caused by something other than a suddenly massively congested network then this tweak lets TCP get back to a reasonable operating point more rapidly. So, a couple of questions ... and, the authors current hits ... (1) Is this change in-scope for 2581bis? We said "no algorithmic tweaks" and so one view is that this should be cooked elsewhere and rolled in later. The author's hit on this is that the behavior of slamming ssthresh down on the first backed off RTO is not our intent and so tweaking this seems in-scope. =20 (2) Assuming folks are fine with making a change then which change should we make? Suggestion #1 or #2? The author's chatted and we feel like #2 is fine. As noted above, neither case really aggravates the state of the network in suddenly heavily loaded situations. So, #2 seems OK. What do people think? Is #2 OK? Or, something else? Thanks in advance for the feedback! allman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 31 11:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Zfk-0002q1-BJ; Mon, 31 Jul 2006 11:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Zfi-0002pw-UJ for tcpm@ietf.org; Mon, 31 Jul 2006 11:27:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Zfh-0004oV-FN for tcpm@ietf.org; Mon, 31 Jul 2006 11:27:10 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2006 08:27:08 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="437640131:sNHT28103240" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VFR8mE021685; Mon, 31 Jul 2006 08:27:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6VFR8Yr014972; Mon, 31 Jul 2006 08:27:08 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 08:27:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] revising 2581: setting ssthresh on RTOs Date: Mon, 31 Jul 2006 08:27:07 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801EB477B@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] revising 2581: setting ssthresh on RTOs Thread-Index: Aca0l1pmDNbVeR5jQSe/KViGFptVBwAHElhg From: "Anantha Ramaiah \(ananth\)" To: , X-OriginalArrivalTime: 31 Jul 2006 15:27:08.0465 (UTC) FILETIME=[C938A210:01C6B4B5] DKIM-Signature: a=rsa-sha1; q=dns; l=4684; t=1154359628; x=1155223628; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20revising=202581=3A=20setting=20ssthresh=20on=20RTOs; X=v=3Dcisco.com=3B=20h=3D4PVkPvBjEqPSwlXtfjgd1bngvBY=3D; b=msaUPao7cHi0POAQSLeOTK5UB4KU0LpG4UlL2suOM9rlTKSkrUyJgdJ+djGJdCKQIn+R4LYx V9s7FGOm3C0YAa58t9tdkhfLADMzWXQ6/JtEG3EOcMKMOaodjBd2cpoE; Authentication-Results: sj-dkim-3.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark: Here is my take : - I am fine to make this change in RFC2581bis. Although I really don't have a strong argument one way or the other regarding the scope, I would vote for making this change in RFC2581. - Option #2 is the way I would go. My argument on favour of #2 is that vast majority of the internet has undergone a sea change in terms of processing HP of the routers, bandwidth, speed of the link etc., and recovery mechanisms needs to quickly adapt to the transient conditions arising in these networks. I think having a larger ssthresh than before (after successive RTO's) is fine and I see no major issues here. $0.02, -Anantha =20 > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org]=20 > Sent: Monday, July 31, 2006 4:47 AM > To: tcpm@ietf.org > Subject: [tcpm] revising 2581: setting ssthresh on RTOs >=20 > =20 > Folks- >=20 > We have talked about setting ssthresh after RTOs on this list=20 > a number of times and we talked about it in Montreal. I'd=20 > like to verify what seemed the general mood in Montreal here=20 > on the list. I think this is the last bit we need to work=20 > out on 2581bis. If you have something else that you think=20 > needs done to the document, please yell. >=20 > RFC 2581 says that on each RTO a TCP reduces ssthresh to=20 > FlightSize / 2. Consider a lost retransmit. Say we RTO on=20 > segment X, cut ssthresh to Y segments (Y > 2 - just for the=20 > example), cwnd becomes 1 segment and the RTO is backed off. =20 > Now, say we RTO on segment X again. The cwnd will stay at=20 > one, but the FlightSize is now 1 and so ssthresh takes its=20 > minimum value of 2 segments. >=20 > The observation is that this forces linear growth for a=20 > potentially long time if this loss hiccup was caused by some=20 > small network issue like a handoff. In that case, it'd be=20 > nice to be able to keep ssthresh higher and use slow start=20 > when packets started flowing again. >=20 > Also, as a practical matter I don't think the above scenario=20 > is the way we intended things to work. Rather, I think we=20 > envisioned (but, alas, did not write) suggestion #1: >=20 > Suggestion #1: On the first RTO for some segment, set=20 > ssthresh to FlightSize/2. On each subsequent RTO for the=20 > given segment halve ssthresh (ssthresh =3D/ 2). >=20 > Basically, this slowly degrades ssthresh as the RTO gets=20 > backed off, such that the longer TCP has been transmitting=20 > into a lousy network the less the TCP gets to use exponential=20 > increase when packets start flowing again. >=20 > In addition, another variant has been suggested in the meantime, ... >=20 > Suggestion #2: On the first RTO for some segment, set=20 > ssthresh to FlightSize/2. On each subsequent RTO for the=20 > given segment do not adjust ssthresh at all. >=20 > This variant means that a TCP always gets to re-probe with=20 > slow start based on the pre-loss conditions no matter how=20 > long it took to fix the loss.=20 >=20 > Both #1 and #2 are quite safe. If the network is in a really=20 > lousy state then the TCP is going to continue to get losses=20 > even after getting out of RTO backoff without increasing the=20 > congestion window all that much. And, if that happens then=20 > ssthresh will get further reduced (probably to its minimum). =20 > Essentially, if the network is heavily loaded all of the=20 > sudden then this additional loss isn't really going to be=20 > exacerbated by the first couple RTTs of slow start. If the=20 > backoff was caused by something other than a suddenly=20 > massively congested network then this tweak lets TCP get back=20 > to a reasonable operating point more rapidly. >=20 > So, a couple of questions ... and, the authors current hits ... >=20 > (1) Is this change in-scope for 2581bis? We said "no algorithmic > tweaks" and so one view is that this should be cooked=20 > elsewhere and > rolled in later. >=20 > The author's hit on this is that the behavior of slamming ssthresh > down on the first backed off RTO is not our intent and so tweaking > this seems in-scope. =20 >=20 > (2) Assuming folks are fine with making a change then which change > should we make? Suggestion #1 or #2? >=20 > The author's chatted and we feel like #2 is fine. As noted above, > neither case really aggravates the state of the network=20 > in suddenly > heavily loaded situations. So, #2 seems OK. >=20 > What do people think? Is #2 OK? Or, something else? >=20 > Thanks in advance for the feedback! >=20 > allman >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 31 16:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eAy-00080G-0R; Mon, 31 Jul 2006 16:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eAw-00080B-JJ for tcpm@ietf.org; Mon, 31 Jul 2006 16:15:42 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7eAv-0001IA-6b for tcpm@ietf.org; Mon, 31 Jul 2006 16:15:42 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.6/8.13.0) with ESMTP id k6VKFbgM021420 for ; Mon, 31 Jul 2006 13:15:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [tcpm] revising 2581: setting ssthresh on RTOs Date: Mon, 31 Jul 2006 13:15:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] revising 2581: setting ssthresh on RTOs Thread-Index: Aca0unH9ajVBOzuCT3O7NdrtCis3EgAI3ThA From: "Mahdavi, Jamshid" To: X-Scanned-By: MIMEDefang 2.55 on 216.52.23.28 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I also agree with option #2. --Jamshid=20 -----Original Message----- Date: Mon, 31 Jul 2006 07:47:29 -0400 From: Mark Allman Subject: [tcpm] revising 2581: setting ssthresh on RTOs To: tcpm@ietf.org Message-ID: <20060731114729.4E9524453E7@lawyers.icir.org> Content-Type: text/plain; charset=3D"us-ascii" =20 Folks- We have talked about setting ssthresh after RTOs on this list a number of times and we talked about it in Montreal. I'd like to verify what seemed the general mood in Montreal here on the list. I think this is the last bit we need to work out on 2581bis. If you have something else that you think needs done to the document, please yell. RFC 2581 says that on each RTO a TCP reduces ssthresh to FlightSize / 2. Consider a lost retransmit. Say we RTO on segment X, cut ssthresh to Y segments (Y > 2 - just for the example), cwnd becomes 1 segment and the RTO is backed off. Now, say we RTO on segment X again. The cwnd will stay at one, but the FlightSize is now 1 and so ssthresh takes its minimum value of 2 segments. The observation is that this forces linear growth for a potentially long time if this loss hiccup was caused by some small network issue like a handoff. In that case, it'd be nice to be able to keep ssthresh higher and use slow start when packets started flowing again. Also, as a practical matter I don't think the above scenario is the way we intended things to work. Rather, I think we envisioned (but, alas, did not write) suggestion #1: Suggestion #1: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment halve ssthresh (ssthresh =3D/ 2). Basically, this slowly degrades ssthresh as the RTO gets backed off, such that the longer TCP has been transmitting into a lousy network the less the TCP gets to use exponential increase when packets start flowing again. In addition, another variant has been suggested in the meantime, ... Suggestion #2: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment do not adjust ssthresh at all. This variant means that a TCP always gets to re-probe with slow start based on the pre-loss conditions no matter how long it took to fix the loss.=20 Both #1 and #2 are quite safe. If the network is in a really lousy state then the TCP is going to continue to get losses even after getting out of RTO backoff without increasing the congestion window all that much. And, if that happens then ssthresh will get further reduced (probably to its minimum). Essentially, if the network is heavily loaded all of the sudden then this additional loss isn't really going to be exacerbated by the first couple RTTs of slow start. If the backoff was caused by something other than a suddenly massively congested network then this tweak lets TCP get back to a reasonable operating point more rapidly. So, a couple of questions ... and, the authors current hits ... (1) Is this change in-scope for 2581bis? We said "no algorithmic tweaks" and so one view is that this should be cooked elsewhere and rolled in later. The author's hit on this is that the behavior of slamming ssthresh down on the first backed off RTO is not our intent and so tweaking this seems in-scope. =20 (2) Assuming folks are fine with making a change then which change should we make? Suggestion #1 or #2? The author's chatted and we feel like #2 is fine. As noted above, neither case really aggravates the state of the network in suddenly heavily loaded situations. So, #2 seems OK. What do people think? Is #2 OK? Or, something else? Thanks in advance for the feedback! allman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 31 18:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ftz-0003n6-QT; Mon, 31 Jul 2006 18:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7fty-0003ja-Gi for tcpm@ietf.org; Mon, 31 Jul 2006 18:06:18 -0400 Received: from maila.microsoft.com ([131.107.1.7] helo=mail2.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ftx-00019E-4j for tcpm@ietf.org; Mon, 31 Jul 2006 18:06:18 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 15:06:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Mon, 31 Jul 2006 15:06:15 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] revising 2581: setting ssthresh on RTOs Date: Mon, 31 Jul 2006 15:06:06 -0700 Message-ID: In-Reply-To: <20060731114729.4E9524453E7@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] revising 2581: setting ssthresh on RTOs Thread-Index: Aca0l1KPgwHtyyuWR5KCpLY/72JbJQAVcC7g From: "Murari Sridharan" To: , X-OriginalArrivalTime: 31 Jul 2006 22:06:15.0895 (UTC) FILETIME=[8B007670:01C6B4ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org #2 definitely looks reasonable.=20 Although given the scenario you are targeting "hiccup was caused by some small network issue like a handoff" which seems specific to a wireless setting, or even if it not, a sender that implements F-RTO can detect that the RTO is spurious and in which case could potentially revert the congestion control parameters to pre-loss thresholds.=20 Murari=20 -----Original Message----- From: Mark Allman [mailto:mallman@icir.org]=20 Sent: Monday, July 31, 2006 4:47 AM To: tcpm@ietf.org Subject: [tcpm] revising 2581: setting ssthresh on RTOs =20 Folks- We have talked about setting ssthresh after RTOs on this list a number of times and we talked about it in Montreal. I'd like to verify what seemed the general mood in Montreal here on the list. I think this is the last bit we need to work out on 2581bis. If you have something else that you think needs done to the document, please yell. RFC 2581 says that on each RTO a TCP reduces ssthresh to FlightSize / 2. Consider a lost retransmit. Say we RTO on segment X, cut ssthresh to Y segments (Y > 2 - just for the example), cwnd becomes 1 segment and the RTO is backed off. Now, say we RTO on segment X again. The cwnd will stay at one, but the FlightSize is now 1 and so ssthresh takes its minimum value of 2 segments. The observation is that this forces linear growth for a potentially long time if this loss hiccup was caused by some small network issue like a handoff. In that case, it'd be nice to be able to keep ssthresh higher and use slow start when packets started flowing again. Also, as a practical matter I don't think the above scenario is the way we intended things to work. Rather, I think we envisioned (but, alas, did not write) suggestion #1: Suggestion #1: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment halve ssthresh (ssthresh =3D/ 2). Basically, this slowly degrades ssthresh as the RTO gets backed off, such that the longer TCP has been transmitting into a lousy network the less the TCP gets to use exponential increase when packets start flowing again. In addition, another variant has been suggested in the meantime, ... Suggestion #2: On the first RTO for some segment, set ssthresh to FlightSize/2. On each subsequent RTO for the given segment do not adjust ssthresh at all. This variant means that a TCP always gets to re-probe with slow start based on the pre-loss conditions no matter how long it took to fix the loss.=20 Both #1 and #2 are quite safe. If the network is in a really lousy state then the TCP is going to continue to get losses even after getting out of RTO backoff without increasing the congestion window all that much. And, if that happens then ssthresh will get further reduced (probably to its minimum). Essentially, if the network is heavily loaded all of the sudden then this additional loss isn't really going to be exacerbated by the first couple RTTs of slow start. If the backoff was caused by something other than a suddenly massively congested network then this tweak lets TCP get back to a reasonable operating point more rapidly. So, a couple of questions ... and, the authors current hits ... (1) Is this change in-scope for 2581bis? We said "no algorithmic tweaks" and so one view is that this should be cooked elsewhere and rolled in later. The author's hit on this is that the behavior of slamming ssthresh down on the first backed off RTO is not our intent and so tweaking this seems in-scope. =20 (2) Assuming folks are fine with making a change then which change should we make? Suggestion #1 or #2? The author's chatted and we feel like #2 is fine. As noted above, neither case really aggravates the state of the network in suddenly heavily loaded situations. So, #2 seems OK. What do people think? Is #2 OK? Or, something else? Thanks in advance for the feedback! allman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 31 23:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7lEX-0007N9-To; Mon, 31 Jul 2006 23:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7lEW-0007N1-KV for tcpm@ietf.org; Mon, 31 Jul 2006 23:47:52 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7lEV-0004Wp-9c for tcpm@ietf.org; Mon, 31 Jul 2006 23:47:52 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k713lkEk084294; Mon, 31 Jul 2006 20:47:50 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id BAD7277B07A; Mon, 31 Jul 2006 23:47:43 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 91277445A2C; Mon, 31 Jul 2006 23:46:30 -0400 (EDT) To: "Murari Sridharan" From: Mark Allman Subject: Re: [tcpm] revising 2581: setting ssthresh on RTOs In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Into the Great Wide Open MIME-Version: 1.0 Date: Mon, 31 Jul 2006 23:46:30 -0400 Message-Id: <20060801034630.91277445A2C@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1283232068==" Errors-To: tcpm-bounces@ietf.org --===============1283232068== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > #2 definitely looks reasonable. Thanks. > Although given the scenario you are targeting "hiccup was caused by > some small network issue like a handoff" which seems specific to a > wireless setting, or even if it not, a sender that implements F-RTO > can detect that the RTO is spurious and in which case could > potentially revert the congestion control parameters to pre-loss > thresholds. *If* the RTOs are spurious. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEzs6WWyrrWs4yIs4RAkPpAJ98clCIrgqYtxrVlZcks7sevvmCnwCfRlF3 xyR+TQMp6ZWpfzCh1nNQ1fQ= =vn9I -----END PGP SIGNATURE----- --=_bOundary-- --===============1283232068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1283232068==--