From tcpm-bounces@ietf.org Thu Jun 01 00:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flegm-00060f-Ds; Thu, 01 Jun 2006 00:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flegk-0005yK-Cj for tcpm@ietf.org; Thu, 01 Jun 2006 00:21:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flegj-0003Eo-V2 for tcpm@ietf.org; Thu, 01 Jun 2006 00:21:38 -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 k514JfI00246; Wed, 31 May 2006 21:19:41 -0700 (PDT) Message-ID: <447E6AD4.2040300@isi.edu> Date: Wed, 31 May 2006 21:19:32 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> <447CE009.5050503@isi.edu> <20060531004504.GL1309@hut.isi.edu> <447CEF93.3010400@isi.edu> <7.0.1.0.0.20060531200816.03493c00@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060531200816.03493c00@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: 7da5a831c477fb6ef97f379a05fb683c 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="===============0739421334==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0739421334== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig07E12689B75D4C8AA214FA47" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07E12689B75D4C8AA214FA47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 22:21 30/05/2006, Joe Touch wrote: >=20 >> > Or you're saying something else? >> >> 4301 says, basically, that ICMPs present a conundrum: >> >> - accepting them presents a way to degrade service (an attack) >> >> - dropping them degrades service (sort of like you're attacking yourse= lf) >=20 > The issue is that if you're securing a connection with IPSec, you > require authentication for the packets that correspond to the > connection, but you cannot enforce the same for the ICMP error messages= > that refer to that connection. In *that* case, you *may* choose either > to drop ICMPs. >=20 > RFC 4301 leaves it up to the administrator. >=20 > And it makes it clear that in the case of PMTUD, you're in trouble. > IIRC, it sort of suggest to honor the "frag needed" messages but enforc= e > a lower limit for the Path-MTU. >=20 > I'd not take that as a recommendation to "drop all ICMPs". The doc is clear IMO that if accepting unauthenticated ICMPs is more of an attack than dropping ICMPs, then drop. PMTUD is a problem in that case; that's the purpose of the solutions being discussed in the PMTUD WG which don't rely on ICMP. > Now, in the case on non IPSec'ed connections, what's it that makes you > trust a TCP segment, but not an ICMP error message? In some cases, it's the partial deployment of ingress filtering. It'd be harder to spoof a TCP segment from a particular source than an ICMP from an arbitrary node on the path. In other cases it's the presence of TCP authentication data (e.g., TCP/MD5). Finally, the TCP checksum (see below= ). > The TCP segments are not authenticated, either. They can be. > Yes, there are issues in the ICMP specs that need to be fixed. > Clearly, the specs should have always required ICMP error messages to b= e > in-window. TCP specs are very clear - and we've gone over this too - that it's inappropriate to parse the TCP header if the checksum isn't correct. For ICMP messages with intact TCP segments, yes, in-window makes sense. >> The key question here is whether there is any real disagreement that >> dropping all ICMPs is the first and most prevalent line of defense fro= m >> attack. The doc isn't recommending it, but it is stating that. >=20 > That's your assumption. I gave the general citations that talk about firewalls blocking all ICMPs - CAIDA, NLANR, and NANOG all mention it repeatedly enough that a citation itself should not be necessary. > The most prevalent defense against ICMP-based connection-reset attacks > is simply to take the hard errors as a hint, for example. >=20 > Again, run traceroute or ping. That will give you a hint to what extent= > there's a prevalence of "drop all ICMPs". The trouble with both NATs and firewalls is that you don't see what's behind them. It's hard to count what you can't see. >> Is that >> something we need to have 'rough consensus' on? If so, can some others= >> please start reading the CAIDA/NLANR/NANOG docs and meeting notes, so = we >> can proceed? >=20 > I cannot understand why you oppose so much to performing checks on ICMP= > messages and taking the error messages as "hints", and at the same time= > encourage (one way or the other) people to drop all ICMPs. The scenarios differ. TCP-antispoof is about TCP under attack. The doc already shows that such attacks are likely only when both endpoint IP addresses and the service address are known; that's not the case except for routing protocols and some network services (proxy-proxy). Yes, if those systems are under attack, they ought to run with very small packet sizes (to minimize PMTU issues) and drop all ICMPs. That behavior is consistent with existing specs - it takes a SHOULD down to MUST NOT but only under very specific conditions. No, the rest of us don't need to do that. That would take the SHOULD to a MUST NOT for all, which would be a change to the standards. I don't see a reason to change the standards on this point at this time. As to hints, then you can't eat your cake and have it too. If you want to parse the TCP header, then follow TCP rules - if the checksum isn't valid, you shouldn't be parsing it, period. And as to the rest of the hints, they're based on the assumption that everything you don't expect is an attack - which is NOT what this doc is discussing. This doc is discussing a system under attack. Joe --------------enig07E12689B75D4C8AA214FA47 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 iD8DBQFEfmrYE5f5cImnZrsRAimZAKD9FKzCUdl/Pi7sIPu6i82rPHqHOACfUF4O zUw36lt/nrQwjH2GzENsp5A= =IGca -----END PGP SIGNATURE----- --------------enig07E12689B75D4C8AA214FA47-- --===============0739421334== 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 --===============0739421334==-- From tcpm-bounces@ietf.org Thu Jun 01 06:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkRa-0004qs-H8; Thu, 01 Jun 2006 06:30:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkRZ-0004qf-1N for tcpm@ietf.org; Thu, 01 Jun 2006 06:30:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlkRX-0008Jp-Gq for tcpm@ietf.org; Thu, 01 Jun 2006 06:30:21 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k51AUGcW013127; Thu, 1 Jun 2006 13:30:16 +0300 Date: Thu, 1 Jun 2006 13:30:16 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <447DA804.8080406@isi.edu> Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B24ED.1020307@isi.edu> <447DA804.8080406@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1504/Wed May 31 22:59:14 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- TTL checking 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 Wed, 31 May 2006, Joe Touch wrote: >> On Mon, 29 May 2006, Joe Touch wrote: >>>> >>>> The text in section 3.2.1 about TTL checking is still misleading or >>>> incorrect. Do you mean both you and your peer with "those nodes" in "or >>>> any traffic those nodes accept via tunnels - because tunnels need not >>>> decrement TTLs"? Either way, this gets back to whether your peer is >>>> complying to RFC 791, i.e., decrementing the TTL for packets which it >>>> forwards. There is no difference whether the link is physical or an IP >>>> tunnel. Tunnel head-end decrements the TTL if it forwards a packet to >>>> the tunnel; tunnel tail-end decrements the TTL if it forwards a packet >>>> out of the tunnel. TTL is unchanged for packets at the end which is >>>> originating or receiving packets. Exactly like physical interfaces. >>> >>> See section 3.1 of RFC2003; whether the TTL is decremented depends on >>> whether forwarding is considered part of the operation, and this is a >>> choice, not fixed. >>> >>> Can you evaluate the remainder of this note in the context of RFC2003 >>> and let us know if there is still an inconsistency? >> >> In my opinion, RFC 2003 section 3.1 (specifically the third-to-last and >> second-to-last paragraphs) says exactly the same thing as I say. The TTL >> is decremented if tunneling is a step in forwarding a datagram, not >> otherwise. Just like with a physical interface. The bottom line is >> that a compliant RFC 2003 encapsulator will decrement TTL for packets >> which it forwards. > > (presumably you mean decapsulator, not the encapsulator) Both will decrement TTL when forwarding, but encapsulator is of (security) interest here. > RFC2003, sec 3.1, third-to-last (emphasis mine): > > When encapsulating a datagram, the TTL in the inner IP header is > decremented by one **if the tunneling is being done as part of > forwarding the datagram**; **otherwise, the inner header TTL is not > changed during encapsulation**. If the resulting TTL in the inner IP > header is 0, the datagram is discarded and an ICMP Time Exceeded > message SHOULD be returned to the sender. An encapsulator MUST NOT > encapsulate a datagram with TTL = 0. > > If that packet is generated at that node, or if the packet is sent to > the tunnel in a non-forwarding (BITW) step, that decrement would not happen. > > The TTL in the inner IP header is **not changed when decapsulating**. > If, after decapsulation, the inner datagram has TTL = 0, the > decapsulator MUST discard the datagram. If, after decapsulation, the > decapsulator forwards the datagram to one of its network interfaces, > **it will decrement the TTL as a result of doing normal IP forwarding**. > See also Section 4.4. > > The decapsulator decrements only if forwarding - again, if the packet > stops at the destination or if the device isn't a forwarder (BITW), that > wouldn't happen. That's an interesting interpretation. Mine would be that it's just a choice of words to refer to forwarding. BITW is similar to L2 encapsulation of IP datagrams in this context in the sense that the encapsulator is invisible from the IP layer perspective. I doubt RFC 2003 was even intended to cover BITW implementations. It'd probably make sense to continue this discussion on int-area list. -- 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 Jun 01 10:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloaR-0007jB-0e; Thu, 01 Jun 2006 10:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloaO-0007fs-Vx for tcpm@ietf.org; Thu, 01 Jun 2006 10:55:44 -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 1FloaO-00037I-Tn for tcpm@ietf.org; Thu, 01 Jun 2006 10:55:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FloaN-0003yk-SF for tcpm@ietf.org; Thu, 01 Jun 2006 10:55:44 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2006 07:55:43 -0700 X-IronPort-AV: i="4.05,197,1146466800"; d="scan'208"; a="286981599:sNHT38941212" 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 k51EthG9027896; Thu, 1 Jun 2006 07:55:43 -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 k51EthKP003422; Thu, 1 Jun 2006 07:55:43 -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, 1 Jun 2006 07:55:43 -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, 1 Jun 2006 07:55:42 -0700 Message-ID: <447EFFFD.1020603@cisco.com> Date: Thu, 01 Jun 2006 10:55: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: Joe Touch Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <54AD0F12E08D1541B826BE97C98F99F149F6D2@NT-SJCA-0751.brcm.ad.broadcom.com> <446CD8D9.90006@isi.edu> In-Reply-To: <446CD8D9.90006@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2006 14:55:42.0291 (UTC) FILETIME=[74305230:01C6858B] DKIM-Signature: a=rsa-sha1; q=dns; l=2723; t=1149173743; x=1150037743; c=relaxed/simple; s=sjdkim4001; 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]=20draft-ietf-rddp-mpa-03.txt=20review=20request; X=v=3Dcisco.com=3B=20h=3D6QQFGxf5bNs4Ml+163U1NZ4Sbaw=3D; b=vZs4A5pqEuOmgLvsYOHrlnc7erVq564b3VnNjnmCjGRppFhfdVsB2icePzVHMd/uUVcmh44+ mWVMLmJmmWuO0iDCj1uW7EI7J3lDnO9GsrZnVps5fX5hz3Qkpp8+jrXv; Authentication-Results: sj-dkim-4.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Yes. With retransmission alone all bets are off. > > This is the Nth time this dog has been dragged around the block. > > It also assumes that the sends match the PDUs; if they're ever larger, > that and all subsequent segments will be misaligned in those > implementations. How do you know when the path changes? There are no > signals in TCP's API to tell the app when the MTU changes, or - more > importantly - to tell them that it changed and all the queued data will > be segmented differently. > > This is just a bad idea. Joe/All: Ok, I have read through this thread.. quite late.. and have a question related to the above... I get how a retransmission will cause resegmentation... and mess up MPA.. but is there not another case that no one as brought up that happens more on the norm... Consider a MPA sender sending 512 byte blocks (I do this for convience almost any size will do).. and assume we have a LOT of these to send... say at least 10. Now lets start with an intial cwnd = 4380... Now we start sending are 512 byte blocks 1:----send(512)----> to wire 2:----send(512)----> to wire ... 8:----send(512)----> to wire 9:----send(512)----> XXXX 10:---send(512)----> At the XXXX above we would NOT send the whole thing on the wire.. instead you will get 284 bytes sent to fill the cwnd. When the first ACK comes back you will then get the rest+512 bytes out... This is a NORMAL non-retransmission scheme where this would happen on a regular basis in a LOT of different forms.. Would not this cause additional issues... now I am by far not a TCP expert... not unless you flip two letters and stick an S in front of it :-D But we have seen an issue like this with SCTP... where we have to allow a "slop" over the cwnd otherwise the cwnd never grows... TCP never had this problem.. since if there was just a bit of room it can re-segment and transmit just a small piece to fill the cwnd exactly.... It seems to me this is an additional issue that one will find with "standard" TCP stacks.. and for new stacks they build to do MPA they will run in to the issue that they stop at segment 8 (above).. and then when the sack arrives they can send there segment.. but this also means (at least IMO) they are NOT using the full cwnd.. and thus should NOT be allowed to grow it ... A rather interesting issue that they need to address (if they have not already).. I confess I have not read the MPA draft anytime recently... so they may have a work-around for this... Just some thoughts.. late though they are :-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 Fri Jun 02 02:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2pq-0004sO-3U; Fri, 02 Jun 2006 02:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2pp-0004sG-Bd for tcpm@ietf.org; Fri, 02 Jun 2006 02:08:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm2pi-0002Ok-Fu for tcpm@ietf.org; Fri, 02 Jun 2006 02:08:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k5268Q4l013485; Fri, 2 Jun 2006 09:08:27 +0300 Date: Fri, 2 Jun 2006 09:08:26 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <447B25E7.50901@isi.edu> Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1505/Thu Jun 1 21:29:37 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation 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 Mon, 29 May 2006, Joe Touch wrote: >> Unfortunately, [ICMP errors] also can originate at other places >> in the network. As a result, >> many networks filter all ICMP packets because validation may not be >> possible, especially because they can be injected from anywhere in a >> network, and so cannot be selectively address filtered. >> >> .. it seems that "As a result" is speculative. I don't know why people >> filter ICMPs; because there is no reference, I suspect you don't know >> either. > > I'll add a citation to RFC4301, which asserts these reasons (without > citation, FWIW). If you said "[RFC4301] speculates that" instead of "As a result," it would be better. Any language that makes it clear that we're not talking about hard facts would be an improvement. As for the other statement in the next messages of the thread: >> Just for clarity, are you asserting that that recommendation is >> articulated by 4301 or that "all right-thinking networkers" should see >> it that way? > >I'm saying that the security folk saw it that way. That's a big generalization. "Security folks" is a much wider set of people who were actively involved with RFC 4301. In many security people's minds, IPsec is not useful for much more than creating VPNs (the author of said specifications excluded). Look no further than the recent discussion on SAAG for this. Hence 4301's recommendations (or more correctly lack thereof) of ICMP processing are in real world only applicable in the context of VPNs. Hence, while RFC 4301 does include some useful discussion on this, I don't think there are any conclusions there that would be useful in any way in determining TCP's ICMP processing approach. >> You make it seem that filtering ICMPs is a result of certain >> bad ICMP packets, in particular ICMPs which reset sessions. I personally >> suspect that reasons are very different and have evolved much earlier >> on, like "we don't want to allow ping scanning to see which hosts are up". > > Those are outgoing ICMPs; those are filtered for other reasons, > including router load as well as address scanning. Incoming ICMPs are > either information about the external world (which is good) or attacks > (which is bad). The above text can be read to apply to either or both of inbound and outbound ICMP filtering. The text does not make any sense for outbound ICMPs though, for many reasons [1]. I also do not agree with your observation that outgoing ICMPs are generally blocked. I might agree with that in some high-security environments, where typically also all the other outgoing traffic (excluding exceptions, proxies, etc.) is blocked. [1] such as: - the only reason I can think of to block outgoing ICMPs at site edge is to prevent revealing information about the topology, hosts, etc. of the site. That's not the reason you're citing. - why should the originator of ICMP errors care whether the recipient can process them (or not)? It's the recipient's problem to decide whether the error message is to be accepted. - if your site is originating ICMP errors, especially if the site employs ingress filtering, it can perform address filtering (source address) on those errors. -- 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 Fri Jun 02 10:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmARK-0005aL-4P; Fri, 02 Jun 2006 10:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmARJ-0005W7-9q for tcpm@ietf.org; Fri, 02 Jun 2006 10:15:49 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmARI-0001xF-SO for tcpm@ietf.org; Fri, 02 Jun 2006 10:15:49 -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 k52EFKI04021; Fri, 2 Jun 2006 07:15:20 -0700 (PDT) Message-ID: <448047F2.2010500@isi.edu> Date: Fri, 02 Jun 2006 07:15:14 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@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: 200d029292fbb60d25b263122ced50fc Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation 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="===============0259788071==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0259788071== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4468E8133FA4EB26F0106B9D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4468E8133FA4EB26F0106B9D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Mon, 29 May 2006, Joe Touch wrote: >>> Unfortunately, [ICMP errors] also can originate at other places >>> in the network. As a result, >>> many networks filter all ICMP packets because validation may not b= e >>> possible, especially because they can be injected from anywhere in= a >>> network, and so cannot be selectively address filtered. >>> >>> .. it seems that "As a result" is speculative. I don't know why peop= le >>> filter ICMPs; because there is no reference, I suspect you don't know= >>> either. >> >> I'll add a citation to RFC4301, which asserts these reasons (without >> citation, FWIW). >=20 > If you said "[RFC4301] speculates that" instead of "As a result," it > would be better. Any language that makes it clear that we're not > talking about hard facts would be an improvement. Sure. > As for the other statement in the next messages of the thread: >>> Just for clarity, are you asserting that that recommendation is >>> articulated by 4301 or that "all right-thinking networkers" should se= e >>> it that way? >> >> I'm saying that the security folk saw it that way. >=20 > That's a big generalization. "Security folks" is a much wider set of > people who were actively involved with RFC 4301.=20 Yes. The security folks involved in 4301 saw that the broader set of security folks are doing things this way. There are numerous references in CAIDA and NLANR docs regarding ICMP blocking, the same for NANOG proceedings. 4301's discussion of ICMP processing reflects that community consensus. Further, whether some people believe that IPsec is only for VPNs, that is not what IPsec is designed for. IPsec is designed precisely for some of the uses that we're talking about - securing host-host transmission (which isn't a VPN); that's what transport mode is all about. =2E. > Hence, while RFC 4301 does include some useful discussion on this, I > don't think there are any conclusions there that would be useful in any= > way in determining TCP's ICMP processing approach. If we make security recommendations about ICMP, we need to either cite what SAAG has issued on this topic or consult them IMO. Otherwise we're asserting that we know better. Your note above is equivalent to SAAG members saying that what we decide in TSVWG about transport protocols should be dismissed ikn their groups because it focuses only on the limited uses of TCP - since there's plenty of people in TSVWG who don't think that TCP is sufficient for many applications (SCTP, DCCP, RTP). >>> You make it seem that filtering ICMPs is a result of certain >>> bad ICMP packets, in particular ICMPs which reset sessions. I persona= lly >>> suspect that reasons are very different and have evolved much earlier= >>> on, like "we don't want to allow ping scanning to see which hosts are= >>> up". >> >> Those are outgoing ICMPs; those are filtered for other reasons, >> including router load as well as address scanning. Incoming ICMPs are >> either information about the external world (which is good) or attacks= >> (which is bad). >=20 > The above text can be read to apply to either or both of inbound and > outbound ICMP filtering. The text does not make any sense for outbound= > ICMPs though, for many reasons [1]. >=20 > I also do not agree with your observation that outgoing ICMPs are > generally blocked. I might agree with that in some high-security > environments, where typically also all the other outgoing traffic > (excluding exceptions, proxies, etc.) is blocked. >=20 > [1] such as: > - the only reason I can think of to block outgoing ICMPs at site edge > is to prevent revealing information about the topology, hosts, etc. of > the site. That's not the reason you're citing. That should be noted in the doc, and is the reason I cited in an earlier reply. > - why should the originator of ICMP errors care whether the recipient > can process them (or not)? It's the recipient's problem to decide > whether the error message is to be accepted. Liability. ISPs and enterprises don't want stuff they can't validate leaking out. > - if your site is originating ICMP errors, especially if the site > employs ingress filtering, it can perform address filtering (source > address) on those errors. It needs to perform that filtering on the contents, not just the ICMP headers. That's possible, but not how things typically work now - the switch is more likely be set to 'block all'. My firewall box drops ICMPs out in low protection mode, but drops all in medium and high mode (I had thought it was only in high mode; the rule that made it happen was obscure). Home firewall boxes aren't ultra-high security devices, and yet in 2 of 3 modes it blocks incoming and outgoing ICMPs. In one case all suspect ports are blocked, in the other only a fixed subset of ports is allowed. That's not different from the way things are blocked at enterprise networks either. Joe --------------enig4468E8133FA4EB26F0106B9D 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 iD8DBQFEgEfyE5f5cImnZrsRAtRlAJ9AS2IVxDzUILclh7J0kcUTWlKYjACg8zH3 3i6EVcuyMncGio1sfmysQ2A= =WUqt -----END PGP SIGNATURE----- --------------enig4468E8133FA4EB26F0106B9D-- --===============0259788071== 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 --===============0259788071==-- From tcpm-bounces@ietf.org Sat Jun 03 05:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmShS-0006Pp-1a; Sat, 03 Jun 2006 05:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmShQ-0006Pk-DV for tcpm@ietf.org; Sat, 03 Jun 2006 05:45:40 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmShP-00051t-Rz for tcpm@ietf.org; Sat, 03 Jun 2006 05:45:40 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k539jZsh027421; Sat, 3 Jun 2006 12:45:35 +0300 Date: Sat, 3 Jun 2006 12:45:35 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <448047F2.2010500@isi.edu> Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <448047F2.2010500@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation 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 Hi, Maybe we should try to end this thread soon, as the issue seemed to be only about one sentence implying what the reasons for some peoples' ICMP filtering to be. I don't see how those are relevant to this document, so the easiest way to avoid controversy could probably be to avoid such statements.. Inline, On Fri, 2 Jun 2006, Joe Touch wrote: > There are numerous references in CAIDA and NLANR docs regarding ICMP > blocking, the same for NANOG proceedings. 4301's discussion of ICMP > processing reflects that community consensus. It's well known that there's a lot (though still in the vast minority I think) of ICMP blocking out there, but I'd be very careful before making any conclusions as to why people (or vendors) have done that. I think you may be over-generalizing. 4301's discussion of ICMP processing is in the context of 4301. Making conclusions based what IPsec folks chose to do (basically just provide a toggle, without indicating a default) for IPsec-protected sessions probably does not apply to TCP, or anything that doesn't relate to IPsec for that matter. > Further, whether some people believe that IPsec is only for VPNs, that > is not what IPsec is designed for. IPsec is designed precisely for some > of the uses that we're talking about - securing host-host transmission > (which isn't a VPN); that's what transport mode is all about. Though such uses have seen little (or spotty at best) deployment (AFAICS), and in fact I think the main use of transport mode nowadays is to security gateways and between security gateways (e.g., to protect GRE tunnels). >> Hence, while RFC 4301 does include some useful discussion on this, I >> don't think there are any conclusions there that would be useful in any >> way in determining TCP's ICMP processing approach. > > If we make security recommendations about ICMP, we need to either cite > what SAAG has issued on this topic or consult them IMO. > > Otherwise we're asserting that we know better. Your note above is > equivalent to SAAG members saying that what we decide in TSVWG about > transport protocols should be dismissed ikn their groups because it > focuses only on the limited uses of TCP - since there's plenty of people > in TSVWG who don't think that TCP is sufficient for many applications > (SCTP, DCCP, RTP). I hope you know that getting a consensus statement out of SAAG would take 6 months (minimum), if we'd even be able to obtain one. :-) But I agree that wider review could be useful if folks are realistic and agree that we aren't going to get a consunsus statement on this. I'd suggest one or multiple of the following: - when requesting publication of the document, ask the AD to issue IETF LC for this document - after requesting publication of the document or after the next revision, solicit explicit feedback from the security ADs and the security directorate. - send an open query to SAAG list (IMHO which I doubt is very useful) >> - why should the originator of ICMP errors care whether the recipient >> can process them (or not)? It's the recipient's problem to decide >> whether the error message is to be accepted. > > Liability. ISPs and enterprises don't want stuff they can't validate > leaking out. I don't understand this from the practical point of view, and certainly not for ISPs. Are you referring to financial liability if said outgoing ICMPs were an attack? This doesn't seem to be a very common concern, but nonetheless this is somewhat understandable if and only if the enterprise also blocks all the other (modulo few exceptions) outgoing traffic. And in that case, this issue is in no way ICMP-specific, so we can't make conclusions about such ICMP blocking. >> - if your site is originating ICMP errors, especially if the site >> employs ingress filtering, it can perform address filtering (source >> address) on those errors. > > It needs to perform that filtering on the contents, not just the ICMP > headers. That's possible, but not how things typically work now - the > switch is more likely be set to 'block all'. I guess this gets back to the liability point above. Otherwise validating the contents of _outgoing_ ICMPs doesn't make any sense at all. On the other hand, I'd say there are a lot reasons to block incoming ICMPs, or possibly validate their contexts. I suspect the motivations are very different. -- 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 Wed Jun 07 05:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnubA-00059w-ON; Wed, 07 Jun 2006 05:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnub9-00058t-E0; Wed, 07 Jun 2006 05:45:11 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnub6-00085L-Rz; Wed, 07 Jun 2006 05:45:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7C343200908D; Wed, 7 Jun 2006 11:45:27 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24615-03; Wed, 7 Jun 2006 11:45:27 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 26A6F200908C; Wed, 7 Jun 2006 11:45:27 +0200 (CEST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68A17.0FB37B88" Date: Wed, 7 Jun 2006 11:45:00 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE4008737529AB@venus.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt Thread-Index: AcaFvwCjLyPg7NxXR2yqaMhwRUPAXAEV7gyQ From: "Simon Schuetz" To: , , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Subject: [tcpm] FW: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've published a new draft on minor extensions to TCP to operate more efficiently and fair to competing traffic in the presence of mobility and transient connectivity disruptions. The approach makes use of "connectivity-change indications" that can be provided by lower layers, but does not discuss details of such indications themselves (such investigations on-going in other documents). Feedback from the working groups is highly appreciated. Although sending this announcement to multiple working groups, we would like to have the actual discussion on the TCPM mailing list. For some reason it took some time, but the draft is now reachable at=20 http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt Best regards, Simon=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Posted At: Thursday, June 01, 2006 9:50 PM > Posted To: announce-IDs > Conversation: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt=20 > Subject: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : TCP Response to Lower-Layer=20 > Connectivity-Change Indications > Author(s) : S. Schuetz, et al. > Filename : draft-schuetz-tcpm-tcp-rlci-00.txt > Pages : 23 > Date : 2006-6-1 > =09 > When connectivity characteristics between two hosts change abruptly, > TCP can experience significant delays before resuming transmission in > an efficient manner or TCP can behave unfairly to competing traffic. > This document describes TCP extensions that improve transmission > behavior in response to advisory, lower-layer connectivity-change > indications. The proposed TCP extensions modify the local behavior > of TCP and introduce a new TCP option to signal local connectivity- > change indications to remote peers. Performance gains result from a > more efficient transmission behavior and are not due to an increased > aggressiveness. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rl > ci-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-schuetz-tcpm-tcp-rlci-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: application/octet-stream; name="ATT1728791.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1728791.TXT Content-Disposition: attachment; filename="ATT1728791.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTExNDMyNDAuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2NodWV0ei10Y3BtLXRjcC1y bGNpLTAwLnR4dA0K ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: application/octet-stream; name="draft-schuetz-tcpm-tcp-rlci-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-schuetz-tcpm-tcp-rlci-00.URL Content-Disposition: attachment; filename="draft-schuetz-tcpm-tcp-rlci-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zY2h1ZXR6LXRjcG0tdGNwLXJsY2ktMDAudHh0DQo= ------_=_NextPart_001_01C68A17.0FB37B88 Content-Type: text/plain; name="ATT1728792.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1728792.txt Content-Disposition: attachment; filename="ATT1728792.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C68A17.0FB37B88 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_001_01C68A17.0FB37B88-- From tcpm-bounces@ietf.org Mon Jun 12 13:15:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq0n-0001xS-Tr; Mon, 12 Jun 2006 13:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq0n-0001xN-5r for tcpm@ietf.org; Mon, 12 Jun 2006 13:15:37 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpq0l-0005Xb-N8 for tcpm@ietf.org; Mon, 12 Jun 2006 13:15: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 k5CHFYOm052638 for ; Mon, 12 Jun 2006 10:15:34 -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 20FFF77AC21 for ; Mon, 12 Jun 2006 13:15:33 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Entertainer MIME-Version: 1.0 Date: Mon, 12 Jun 2006 13:15:33 -0400 Message-Id: <20060612171533.20FFF77AC21@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option 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="===============1164041987==" Errors-To: tcpm-bounces@ietf.org --===============1164041987== Content-Type: multipart/signed; boundary="==_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --==_bOundary Content-Type: multipart/mixed; boundary="=_bOundary" --=_bOundary Content-Type: text/plain Content-Disposition: inline fyi --=_bOundary Content-Type: message/rfc822 Content-Disposition: attachment; filename=1468 Content-Description: forwarded message Return-Path: touch@isi.edu Delivery-Date: Fri Jun 9 19:01:15 2006 Return-Path: X-Original-To: mallman@localhost Delivered-To: mallman@localhost.icir.org Received: from localhost (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id A9D3577A71D for ; Fri, 9 Jun 2006 19:01:15 -0400 (EDT) Received: from mailhost.icsi.berkeley.edu [192.150.186.11] by localhost with IMAP (fetchmail-6.2.4) for mallman@localhost (single-drop); Fri, 09 Jun 2006 19:01:15 -0400 (EDT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.9) with ESMTP id k59N0g75010816 for ; Fri, 9 Jun 2006 16:00:42 -0700 (PDT) Received: from megatron.ietf.org (odin.ietf.org [156.154.16.145]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k59N0g6R056896 for ; Fri, 9 Jun 2006 16:00:42 -0700 (PDT) (envelope-from tsvwg-bounces@ietf.org) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopy0-0005km-Uc; Fri, 09 Jun 2006 19:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopxz-0005kP-4u for tsvwg@ietf.org; Fri, 09 Jun 2006 19:00:35 -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 1Fop9d-00071W-NT for tsvwg@ietf.org; Fri, 09 Jun 2006 18:08:33 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fop3u-0000aM-By for tsvwg@ietf.org; Fri, 09 Jun 2006 18:02:44 -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 k59M1V604063; Fri, 9 Jun 2006 15:01:31 -0700 (PDT) Message-ID: <4489EFB6.3020309@isi.edu> Date: Fri, 09 Jun 2006 15:01:26 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: tsvwg@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD427CEA5A73F0E8F35F60B71" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.2 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Tsvwg] new I-D: TCP Simple Authentication Option X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org X-ClamAV: OK X-SpamProbe: SKIPPED X-mallman-sequence: tsvwg This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD427CEA5A73F0E8F35F60B71 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, The following I-D has just been submitted. It is intended to provide a simpler alternative to updating TCP/MD5. Comments welcome. It is currently available at: http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt (and should appear in the usual places very shortly) Joe and Allison --------------------------------------------------- TCPM WG J. Touch Internet Draft USC/ISI Expires: December 2006 A. Mankin June 9, 2006 The TCP Simple Authentication Option draft-touch-tcpm-tcp-simple-auth-00.txt =2E.. Abstract This document specifies a TCP Simple Authentication Option (TCP-SA) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and provides more details on the association of security associations with TCP connections. TCP-SA assumes that rekeying is supported by restarting the TCP connection, and so omits in-band parameter negotiation, session key establishment, and rekeying support; where such features are desired, use of the IPsec suite is recommended. The result is intended to be a simple modification to support current infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to support a larger set of hashes with minimal other system and operational changes. TCP-SA requires no new option identifier, though it is intended to be mutually exclusive with TCP/MD5 on a given TCP connection. --------------enigD427CEA5A73F0E8F35F60B71 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 iD8DBQFEie+2E5f5cImnZrsRAljxAKD0JTR+04T/r/44HsryL8bzDB9UpQCeNRe8 fmfhknxJmA+N3wv3JTnmsf0= =ZCiL -----END PGP SIGNATURE----- --------------enigD427CEA5A73F0E8F35F60B71-- --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEjaE1WyrrWs4yIs4RAufYAJ9EWUuix0YpyonMayY/jIOb2ZwiywCfWuay ngTh7CWyht/xzpEMwtWckAI= =5knq -----END PGP SIGNATURE----- --==_bOundary-- --===============1164041987== 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 --===============1164041987==-- From tcpm-bounces@ietf.org Mon Jun 12 13:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq7C-0004rA-6N; Mon, 12 Jun 2006 13:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq7B-0004r0-AG for tcpm@ietf.org; Mon, 12 Jun 2006 13:22:13 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpq79-00066b-TH for tcpm@ietf.org; Mon, 12 Jun 2006 13:22:13 -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 k5CHKm621947; Mon, 12 Jun 2006 10:20:48 -0700 (PDT) Message-ID: <448DA26A.70202@isi.edu> Date: Mon, 12 Jun 2006 10:20:42 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <20060612171533.20FFF77AC21@guns.icir.org> In-Reply-To: <20060612171533.20FFF77AC21@guns.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: c83ccb5cc10e751496398f1233ca9c3a 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="===============1515201095==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1515201095== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9B0E224E86D56FBB7D763A96" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9B0E224E86D56FBB7D763A96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Yes - I had intended to forward this post to TCPM too ;-) The doc is hoped to be a TCPM WG standards-track item, *if* we decide that fixing TCP/MD5 is useful. An alternative approach, of course, is to encourage the use of IPsec instead; that doc, IMO, ought to come out of SAAG rather than TCPM or even TSVWG, however. Joe Mark Allman wrote: > fyi >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > Subject: > [Tsvwg] new I-D: TCP Simple Authentication Option > From: > Joe Touch > Date: > Fri, 09 Jun 2006 15:01:26 -0700 > To: > tsvwg@ietf.org >=20 > To: > tsvwg@ietf.org >=20 >=20 > Hi, all, >=20 > The following I-D has just been submitted. It is intended to provide a > simpler alternative to updating TCP/MD5. Comments welcome. >=20 > It is currently available at: > http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt > (and should appear in the usual places very shortly) >=20 > Joe and Allison >=20 > --------------------------------------------------- >=20 >=20 > TCPM WG J. Touch= > Internet Draft USC/ISI= > Expires: December 2006 A. Mankin= > June 9, 2006= >=20 >=20 > The TCP Simple Authentication Option > draft-touch-tcpm-tcp-simple-auth-00.txt > ... > Abstract >=20 > This document specifies a TCP Simple Authentication Option (TCP-SA) > which is intended to replace the TCP MD5 Signature option of RFC-238= 5 > (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes an= d > provides more details on the association of security associations > with TCP connections. TCP-SA assumes that rekeying is supported by > restarting the TCP connection, and so omits in-band parameter > negotiation, session key establishment, and rekeying support; where > such features are desired, use of the IPsec suite is recommended. > The result is intended to be a simple modification to support curren= t > infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to > support a larger set of hashes with minimal other system and > operational changes. TCP-SA requires no new option identifier, thoug= h > it is intended to be mutually exclusive with TCP/MD5 on a given TCP > connection. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig9B0E224E86D56FBB7D763A96 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 iD8DBQFEjaJqE5f5cImnZrsRApq3AJ9PxFkzBuKZLedymsPjC78D2pWDfACfSqH8 QGG7djUirrgp+C+E62JuyD8= =uCV6 -----END PGP SIGNATURE----- --------------enig9B0E224E86D56FBB7D763A96-- --===============1515201095== 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 --===============1515201095==-- From tcpm-bounces@ietf.org Mon Jun 12 14:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprF6-0004jj-7T; Mon, 12 Jun 2006 14:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprF4-0004jJ-O7 for tcpm@ietf.org; Mon, 12 Jun 2006 14:34:26 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FprF3-0004zM-Cb for tcpm@ietf.org; Mon, 12 Jun 2006 14:34:26 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 12 Jun 2006 11:34:25 -0700 X-IronPort-AV: i="4.05,228,1146466800"; d="scan'208"; a="558648684:sNHT32719892" Received: from [172.25.42.216] ([172.25.42.216] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 14:34:24 -0400 Message-ID: <448DB3AD.1060605@juniper.net> Date: Mon, 12 Jun 2006 14:34:21 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <20060612171533.20FFF77AC21@guns.icir.org> <448DA26A.70202@isi.edu> In-Reply-To: <448DA26A.70202@isi.edu> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 18:34:24.0396 (UTC) FILETIME=[D41DE4C0:01C68E4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tcpm@ietf.org, mallman@icir.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, In your approach, how would you address the problem of rekeying on the PE-CE interface, where Graceful Restart is least likely to be available and IPSec may be impractical? Also, in Section 4, you say that "Middleboxes may alter TCP options en-route are a kind of attack and would be successfully detected by TCP-SA". How would you deal with situations in which the owner of one or both TCP peers put the middle box in-line, intentionally? Ron Joe Touch wrote: > Hi, all, > > Yes - I had intended to forward this post to TCPM too ;-) > > The doc is hoped to be a TCPM WG standards-track item, *if* we decide > that fixing TCP/MD5 is useful. An alternative approach, of course, is to > encourage the use of IPsec instead; that doc, IMO, ought to come out of > SAAG rather than TCPM or even TSVWG, however. > > Joe > > Mark Allman wrote: > >>fyi >> >> >> >> >>------------------------------------------------------------------------ >> >>Subject: >>[Tsvwg] new I-D: TCP Simple Authentication Option >>From: >>Joe Touch >>Date: >>Fri, 09 Jun 2006 15:01:26 -0700 >>To: >>tsvwg@ietf.org >> >>To: >>tsvwg@ietf.org >> >> >>Hi, all, >> >>The following I-D has just been submitted. It is intended to provide a >>simpler alternative to updating TCP/MD5. Comments welcome. >> >>It is currently available at: >>http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt >>(and should appear in the usual places very shortly) >> >>Joe and Allison >> >>--------------------------------------------------- >> >> >>TCPM WG J. Touch >>Internet Draft USC/ISI >>Expires: December 2006 A. Mankin >> June 9, 2006 >> >> >> The TCP Simple Authentication Option >> draft-touch-tcpm-tcp-simple-auth-00.txt >>... >>Abstract >> >> This document specifies a TCP Simple Authentication Option (TCP-SA) >> which is intended to replace the TCP MD5 Signature option of RFC-2385 >> (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and >> provides more details on the association of security associations >> with TCP connections. TCP-SA assumes that rekeying is supported by >> restarting the TCP connection, and so omits in-band parameter >> negotiation, session key establishment, and rekeying support; where >> such features are desired, use of the IPsec suite is recommended. >> The result is intended to be a simple modification to support current >> infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to >> support a larger set of hashes with minimal other system and >> operational changes. TCP-SA requires no new option identifier, though >> it is intended to be mutually exclusive with TCP/MD5 on a given TCP >> connection. >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www1.ietf.org/mailman/listinfo/tcpm > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 12 14:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprKS-0007mu-LS; Mon, 12 Jun 2006 14:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprKR-0007mp-Th for tcpm@ietf.org; Mon, 12 Jun 2006 14:39:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FprKQ-0005XD-EM for tcpm@ietf.org; Mon, 12 Jun 2006 14:39: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 k5CIdB613219; Mon, 12 Jun 2006 11:39:11 -0700 (PDT) Message-ID: <448DB4C9.1060307@isi.edu> Date: Mon, 12 Jun 2006 11:39:05 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <20060612171533.20FFF77AC21@guns.icir.org> <448DA26A.70202@isi.edu> <448DB3AD.1060605@juniper.net> In-Reply-To: <448DB3AD.1060605@juniper.net> 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: 3d7f2f6612d734db849efa86ea692407 Cc: tcpm@ietf.org, mallman@icir.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="===============2039048604==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2039048604== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig001D5C0E1C3314300E90ABA5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig001D5C0E1C3314300E90ABA5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ron Bonica wrote: > Joe, >=20 > In your approach, how would you address the problem of rekeying on the > PE-CE interface, where Graceful Restart is least likely to be available= > and IPSec may be impractical? The doc is clear on this - it assumes either graceful restart or an application that can handover between two TCP connections itself. > Also, in Section 4, you say that "Middleboxes may alter TCP options > en-route are a kind of attack and would be successfully detected by > TCP-SA". How would you deal with situations in which the owner of one o= r > both TCP peers put the middle box in-line, intentionally? That's an attack that would be successfully detected. ;-) The alternative would be to allow options to be either signed or unsigned on a per-connection basis; that 'bit' ought to be pre-shared along with the key and algorithm if so. That can easily be added. Joe > Joe Touch wrote: >> Hi, all, >> >> Yes - I had intended to forward this post to TCPM too ;-) >> >> The doc is hoped to be a TCPM WG standards-track item, *if* we decide >> that fixing TCP/MD5 is useful. An alternative approach, of course, is = to >> encourage the use of IPsec instead; that doc, IMO, ought to come out o= f >> SAAG rather than TCPM or even TSVWG, however. >> >> Joe >> >> Mark Allman wrote: >> >>> fyi >>> >>> >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> Subject: >>> [Tsvwg] new I-D: TCP Simple Authentication Option >>> From: >>> Joe Touch >>> Date: >>> Fri, 09 Jun 2006 15:01:26 -0700 >>> To: >>> tsvwg@ietf.org >>> >>> To: >>> tsvwg@ietf.org >>> >>> >>> Hi, all, >>> >>> The following I-D has just been submitted. It is intended to provide = a >>> simpler alternative to updating TCP/MD5. Comments welcome. >>> >>> It is currently available at: >>> http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt= >>> (and should appear in the usual places very shortly) >>> >>> Joe and Allison >>> >>> --------------------------------------------------- >>> >>> >>> TCPM WG J. Tou= ch >>> Internet Draft USC/I= SI >>> Expires: December 2006 A. Mank= in >>> June 9, 200= 6 >>> >>> >>> The TCP Simple Authentication Option >>> draft-touch-tcpm-tcp-simple-auth-00.txt >>> ... >>> Abstract >>> >>> This document specifies a TCP Simple Authentication Option (TCP-SA)= >>> which is intended to replace the TCP MD5 Signature option of RFC-23= 85 >>> (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes a= nd >>> provides more details on the association of security associations >>> with TCP connections. TCP-SA assumes that rekeying is supported by >>> restarting the TCP connection, and so omits in-band parameter >>> negotiation, session key establishment, and rekeying support; where= >>> such features are desired, use of the IPsec suite is recommended. >>> The result is intended to be a simple modification to support curre= nt >>> infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to >>> support a larger set of hashes with minimal other system and >>> operational changes. TCP-SA requires no new option identifier, thou= gh >>> it is intended to be mutually exclusive with TCP/MD5 on a given TCP= >>> connection. >>> >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tcpm >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm --------------enig001D5C0E1C3314300E90ABA5 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 iD8DBQFEjbTJE5f5cImnZrsRAk+lAJ9VKlzbirbYi2PX0a92qPAVJlXVqQCfYWMa uiZ7YXTkxdYLz0+WPN2Jeks= =K5PD -----END PGP SIGNATURE----- --------------enig001D5C0E1C3314300E90ABA5-- --===============2039048604== 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 --===============2039048604==-- From tcpm-bounces@ietf.org Mon Jun 12 15:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsOE-0006Pz-B3; Mon, 12 Jun 2006 15:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsOD-0006Pu-F6 for tcpm@ietf.org; Mon, 12 Jun 2006 15:47:57 -0400 Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsOB-0005YB-U2 for tcpm@ietf.org; Mon, 12 Jun 2006 15:47:57 -0400 Received: from [128.251.10.85] ([128.251.10.85]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k5CJlbE8006677; Mon, 12 Jun 2006 14:47:38 -0500 In-Reply-To: <448DA26A.70202@isi.edu> References: <20060612171533.20FFF77AC21@guns.icir.org> <448DA26A.70202@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AD5DF8F-876C-4806-824A-68B20CD7B9CF@alcatel.com> Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Mon, 12 Jun 2006 12:47:36 -0700 To: Joe Touch X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: tcpm@ietf.org, mallman@icir.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 Hi Joe, The main reason for the TCP extended auth proposal is the ability to rollover keys without taking the session down. Adding additional, more secure algorithms is a secondary goal. A key attack vector our customers are concerned about is the disgruntled employee let go or other compromise of the key list. They need to be able to change the keys without interrupting the session and causing routing to suffer. Without this, a new mechanism is not particularly useful. Andrew On Jun 12, 2006, at 10:20 AM, Joe Touch wrote: > Hi, all, > > Yes - I had intended to forward this post to TCPM too ;-) > > The doc is hoped to be a TCPM WG standards-track item, *if* we decide > that fixing TCP/MD5 is useful. An alternative approach, of course, > is to > encourage the use of IPsec instead; that doc, IMO, ought to come > out of > SAAG rather than TCPM or even TSVWG, however. > > Joe > > Mark Allman wrote: >> fyi >> >> >> >> >> --------------------------------------------------------------------- >> --- >> >> Subject: >> [Tsvwg] new I-D: TCP Simple Authentication Option >> From: >> Joe Touch >> Date: >> Fri, 09 Jun 2006 15:01:26 -0700 >> To: >> tsvwg@ietf.org >> >> To: >> tsvwg@ietf.org >> >> >> Hi, all, >> >> The following I-D has just been submitted. It is intended to >> provide a >> simpler alternative to updating TCP/MD5. Comments welcome. >> >> It is currently available at: >> http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt >> (and should appear in the usual places very shortly) >> >> Joe and Allison >> >> --------------------------------------------------- >> >> >> TCPM WG J. >> Touch >> Internet Draft >> USC/ISI >> Expires: December 2006 A. >> Mankin >> June 9, >> 2006 >> >> >> The TCP Simple Authentication Option >> draft-touch-tcpm-tcp-simple-auth-00.txt >> ... >> Abstract >> >> This document specifies a TCP Simple Authentication Option (TCP- >> SA) >> which is intended to replace the TCP MD5 Signature option of >> RFC-2385 >> (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based >> hashes and >> provides more details on the association of security associations >> with TCP connections. TCP-SA assumes that rekeying is supported by >> restarting the TCP connection, and so omits in-band parameter >> negotiation, session key establishment, and rekeying support; >> where >> such features are desired, use of the IPsec suite is recommended. >> The result is intended to be a simple modification to support >> current >> infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to >> support a larger set of hashes with minimal other system and >> operational changes. TCP-SA requires no new option identifier, >> though >> it is intended to be mutually exclusive with TCP/MD5 on a given >> TCP >> connection. >> >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 12 16:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpsrs-0000qK-Sk; Mon, 12 Jun 2006 16:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsUG-000420-RF for tcpm@ietf.org; Mon, 12 Jun 2006 15:54:13 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsUD-00073F-PS for tcpm@ietf.org; Mon, 12 Jun 2006 15:54:12 -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 k5CJro604075; Mon, 12 Jun 2006 12:53:50 -0700 (PDT) Message-ID: <448DC648.20605@isi.edu> Date: Mon, 12 Jun 2006 12:53:44 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Lange Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <20060612171533.20FFF77AC21@guns.icir.org> <448DA26A.70202@isi.edu> <6AD5DF8F-876C-4806-824A-68B20CD7B9CF@alcatel.com> In-Reply-To: <6AD5DF8F-876C-4806-824A-68B20CD7B9CF@alcatel.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: 03169bfe4792634a390035a01a6c6d2f Cc: tcpm@ietf.org, mallman@icir.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="===============0332300549==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0332300549== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A6E5D6B210E0EE54C06F7F6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A6E5D6B210E0EE54C06F7F6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Lange wrote: > Hi Joe, >=20 > The main reason for the TCP extended auth proposal is the ability to > rollover keys without taking the session down. Adding additional, more= > secure algorithms is a secondary goal. I can update my draft to correct that impression. > A key attack vector our customers are concerned about is the disgruntle= d > employee let go or other compromise of the key list. They need to be > able to change the keys without interrupting the session and causing > routing to suffer. Without this, a new mechanism is not particularly > useful. See my draft regarding the ability of routing to accommodate session changes. Joe >=20 > Andrew >=20 > On Jun 12, 2006, at 10:20 AM, Joe Touch wrote: >=20 >> Hi, all, >> >> Yes - I had intended to forward this post to TCPM too ;-) >> >> The doc is hoped to be a TCPM WG standards-track item, *if* we decide >> that fixing TCP/MD5 is useful. An alternative approach, of course, is = to >> encourage the use of IPsec instead; that doc, IMO, ought to come out o= f >> SAAG rather than TCPM or even TSVWG, however. >> >> Joe >> >> Mark Allman wrote: >>> fyi >>> >>> >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> Subject: >>> [Tsvwg] new I-D: TCP Simple Authentication Option >>> From: >>> Joe Touch >>> Date: >>> Fri, 09 Jun 2006 15:01:26 -0700 >>> To: >>> tsvwg@ietf.org >>> >>> To: >>> tsvwg@ietf.org >>> >>> >>> Hi, all, >>> >>> The following I-D has just been submitted. It is intended to provide = a >>> simpler alternative to updating TCP/MD5. Comments welcome. >>> >>> It is currently available at: >>> http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt= >>> (and should appear in the usual places very shortly) >>> >>> Joe and Allison >>> >>> --------------------------------------------------- >>> >>> >>> TCPM WG J. Tou= ch >>> Internet Draft USC/I= SI >>> Expires: December 2006 A. Mank= in >>> June 9, 20= 06 >>> >>> >>> The TCP Simple Authentication Option >>> draft-touch-tcpm-tcp-simple-auth-00.txt >>> ... >>> Abstract >>> >>> This document specifies a TCP Simple Authentication Option (TCP-SA= ) >>> which is intended to replace the TCP MD5 Signature option of RFC-2= 385 >>> (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes = and >>> provides more details on the association of security associations >>> with TCP connections. TCP-SA assumes that rekeying is supported by= >>> restarting the TCP connection, and so omits in-band parameter >>> negotiation, session key establishment, and rekeying support; wher= e >>> such features are desired, use of the IPsec suite is recommended. >>> The result is intended to be a simple modification to support curr= ent >>> infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to= >>> support a larger set of hashes with minimal other system and >>> operational changes. TCP-SA requires no new option identifier, tho= ugh >>> it is intended to be mutually exclusive with TCP/MD5 on a given TC= P >>> connection. >>> >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm --------------enig0A6E5D6B210E0EE54C06F7F6 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 iD8DBQFEjcZIE5f5cImnZrsRAjhGAKDvigDZQsTx5zVYe1VYunoWgGSIrgCgieg0 cX+2XcGE/+ZlPJvZKJuL1hM= =tsG9 -----END PGP SIGNATURE----- --------------enig0A6E5D6B210E0EE54C06F7F6-- --===============0332300549== 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 --===============0332300549==-- From tcpm-bounces@ietf.org Mon Jun 12 16:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptIE-0000ap-Sv; Mon, 12 Jun 2006 16:45:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptID-0000af-OE for tcpm@ietf.org; Mon, 12 Jun 2006 16:45:49 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptIC-0004fV-E7 for tcpm@ietf.org; Mon, 12 Jun 2006 16:45:49 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 12 Jun 2006 13:45:38 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A95772AF; Mon, 12 Jun 2006 13:45:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 864B82AE; Mon, 12 Jun 2006 13:45:38 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DTM68514; Mon, 12 Jun 2006 13:45:38 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 1508920501; Mon, 12 Jun 2006 13:45:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Mon, 12 Jun 2006 13:45:37 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Thread-Index: AcaOWSZAO2/2WrZQRPykEzGbbojOWAAB4RHw From: "Caitlin Bestler" To: "Andrew Lange" , "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061208; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343844443130352E303035362D412D; ENG=IBF; TS=20060612204539; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061208_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68930DF80HW29283932-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tcpm@ietf.org, mallman@icir.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 Andrew Lange wrote: > Hi Joe, >=20 > The main reason for the TCP extended auth proposal is the > ability to rollover keys without taking the session down. > Adding additional, more secure algorithms is a secondary goal. >=20 > A key attack vector our customers are concerned about is the > disgruntled employee let go or other compromise of the key list. > They need to be able to change the keys without interrupting > the session and causing routing to suffer. Without this, a > new mechanism is not particularly useful. >=20 Something about "disgruntled employee" sounds distinctly application domain to me. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 12 16:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptMd-0002xF-66; Mon, 12 Jun 2006 16:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptMc-0002x4-56 for tcpm@ietf.org; Mon, 12 Jun 2006 16:50:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptMa-0004np-QQ for tcpm@ietf.org; Mon, 12 Jun 2006 16:50:22 -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 k5CKnW618194; Mon, 12 Jun 2006 13:49:32 -0700 (PDT) Message-ID: <448DD356.7000909@isi.edu> Date: Mon, 12 Jun 2006 13:49:26 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.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: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org, mallman@icir.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="===============1667106994==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1667106994== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig50C3E34934CCE9157949D56D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig50C3E34934CCE9157949D56D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: > Andrew Lange wrote: >> Hi Joe, >> >> The main reason for the TCP extended auth proposal is the >> ability to rollover keys without taking the session down. >> Adding additional, more secure algorithms is a secondary goal. >> >> A key attack vector our customers are concerned about is the >> disgruntled employee let go or other compromise of the key list. >> They need to be able to change the keys without interrupting >> the session and causing routing to suffer. Without this, a >> new mechanism is not particularly useful. >> >=20 > Something about "disgruntled employee" sounds distinctly > application domain to me. Yeah - and one would hope that wouldn't be frequent enough to design protocols around either ;-) Joe --------------enig50C3E34934CCE9157949D56D 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 iD8DBQFEjdNWE5f5cImnZrsRAvd5AKD7zN4v/wUeDJE6gAwyP0KPT+j2sgCfV/Ip 8KSdVGcIqUJgoKV0dT95PEM= =hc+G -----END PGP SIGNATURE----- --------------enig50C3E34934CCE9157949D56D-- --===============1667106994== 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 --===============1667106994==-- From tcpm-bounces@ietf.org Tue Jun 13 18:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHHI-0002VU-4u; Tue, 13 Jun 2006 18:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHHH-0002VP-BL for tcpm@ietf.org; Tue, 13 Jun 2006 18:22:27 -0400 Received: from hostreea1.alcatel.com ([143.209.238.161] helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHHF-000787-UI for tcpm@ietf.org; Tue, 13 Jun 2006 18:22:27 -0400 Received: from [128.251.10.129] ([128.251.10.129]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id k5DMMMmb026575; Tue, 13 Jun 2006 17:22:23 -0500 In-Reply-To: <448DD356.7000909@isi.edu> References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Tue, 13 Jun 2006 15:22:19 -0700 To: Joe Touch X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, mallman@icir.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, Caitlin, What we do have to design protocols around is user requirements. We also have to design protocols with maximum flexibility and robustness. End users will use the protocols in ways we haven't predicted to meet requirements we don't yet know about. All TCP EXT AUTH does is provide a way to authenticate TCP sessions. It is radically more simple and easier to do this at the TCP layer than to implement something slightly different across a variety of higher- level routing protocols. Andrew On Jun 12, 2006, at 1:49 PM, Joe Touch wrote: > > > Caitlin Bestler wrote: >> Andrew Lange wrote: >>> Hi Joe, >>> >>> The main reason for the TCP extended auth proposal is the >>> ability to rollover keys without taking the session down. >>> Adding additional, more secure algorithms is a secondary goal. >>> >>> A key attack vector our customers are concerned about is the >>> disgruntled employee let go or other compromise of the key list. >>> They need to be able to change the keys without interrupting >>> the session and causing routing to suffer. Without this, a >>> new mechanism is not particularly useful. >>> >> >> Something about "disgruntled employee" sounds distinctly >> application domain to me. > > Yeah - and one would hope that wouldn't be frequent enough to design > protocols around either ;-) > > Joe > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 13 18:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHTF-0007zz-Os; Tue, 13 Jun 2006 18:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHTE-0007wc-NY for tcpm@ietf.org; Tue, 13 Jun 2006 18:34:48 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHTD-0000WX-Bn for tcpm@ietf.org; Tue, 13 Jun 2006 18:34:48 -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 k5DMX9604323; Tue, 13 Jun 2006 15:33:09 -0700 (PDT) Message-ID: <448F3D1E.1060309@isi.edu> Date: Tue, 13 Jun 2006 15:33:02 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Lange Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> In-Reply-To: <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.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: 31247fb3be228bb596db9127becad0bc Cc: tcpm@ietf.org, mallman@icir.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="===============0784164789==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0784164789== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB757368338270445FF6689D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB757368338270445FF6689D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Lange wrote: > Joe, Caitlin, >=20 > What we do have to design protocols around is user requirements. We > also have to design protocols with maximum flexibility and robustness. = > End users will use the protocols in ways we haven't predicted to meet > requirements we don't yet know about. All TCP EXT AUTH does is provid= e > a way to authenticate TCP sessions. It is radically more simple and > easier to do this at the TCP layer than to implement something slightly= > different across a variety of higher-level routing protocols. Those modifications are already underway or implemented in the primary protocol of interest (BGP). These modifications reflect (IMO) an error in protocol design: TCP connectivity was never intended to reflect path viability for routing. Interpreting TCP disconnects as a path failure - which is the only reason to flush the associated routes - is thus an error which it is appropriate to correct. If that's not sufficient, it would be very useful to understand why IPsec isn't more than sufficient to solve the user protocol requirements here. If there are needs beyond the protocol level - e.g., anything involving disgruntled employees fits in here - then it'd be useful to understand why a protocol solution is necessary. Joe > On Jun 12, 2006, at 1:49 PM, Joe Touch wrote: >=20 >> >> >> Caitlin Bestler wrote: >>> Andrew Lange wrote: >>>> Hi Joe, >>>> >>>> The main reason for the TCP extended auth proposal is the >>>> ability to rollover keys without taking the session down. >>>> Adding additional, more secure algorithms is a secondary goal. >>>> >>>> A key attack vector our customers are concerned about is the >>>> disgruntled employee let go or other compromise of the key list. >>>> They need to be able to change the keys without interrupting >>>> the session and causing routing to suffer. Without this, a >>>> new mechanism is not particularly useful. >>>> >>> >>> Something about "disgruntled employee" sounds distinctly >>> application domain to me. >> >> Yeah - and one would hope that wouldn't be frequent enough to design >> protocols around either ;-) >> >> Joe >> --------------enigFB757368338270445FF6689D 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 iD8DBQFEjz0eE5f5cImnZrsRAlG1AJ9TmkE+rV1wmV45vKczOLPxvJMoVwCgifdv iVCRvFvZC+fIRzhD0LzhrbA= =dcYg -----END PGP SIGNATURE----- --------------enigFB757368338270445FF6689D-- --===============0784164789== 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 --===============0784164789==-- From tcpm-bounces@ietf.org Tue Jun 13 18:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHjz-0000vw-1O; Tue, 13 Jun 2006 18:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHjo-0000ty-Ix for tcpm@ietf.org; Tue, 13 Jun 2006 18:51:56 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHjm-0003nc-Uo for tcpm@ietf.org; Tue, 13 Jun 2006 18:51:56 -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 k5DMpjhQ097262; Tue, 13 Jun 2006 15:51:46 -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 A851077A71D; Tue, 13 Jun 2006 18:51:43 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8EB0B423895; Tue, 13 Jun 2006 18:50:40 -0400 (EDT) To: Andrew Lange From: Mark Allman Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option In-Reply-To: <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Pink Houses MIME-Version: 1.0 Date: Tue, 13 Jun 2006 18:50:40 -0400 Message-Id: <20060613225040.8EB0B423895@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org, Joe Touch 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="===============0029866130==" Errors-To: tcpm-bounces@ietf.org --===============0029866130== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Andrew- As a still-puzzled observer... > What we do have to design protocols around is user requirements. We > also have to design protocols with maximum flexibility and robustness. > End users will use the protocols in ways we haven't predicted to meet > requirements we don't yet know about. All TCP EXT AUTH does is > provide a way to authenticate TCP sessions. It is radically more > simple and easier to do this at the TCP layer than to implement > something slightly different across a variety of higher- level routing > protocols. Isn't this shove-it-down-into-a-common-place-in-the-stack-such-that-it- is-"radically more simple easier" notion one of the reasons we ended up with IPsec at the network layer? And, don't routing protocols generally use IP (at least those that use TCP)? In the above you argue for generality. I buy that. But, why don't we use the general notion that has been developed for hardening TCP/IP traffic (IPsec)? Why should we do something different in this case? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEj0E/WyrrWs4yIs4RAq8TAJ4k05s7BhSvTXmzMIOevvlPS2H6lgCfRQCr 3VPV5bN2RbhfWkR7GB4A5jU= =7CLw -----END PGP SIGNATURE----- --=_bOundary-- --===============0029866130== 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 --===============0029866130==-- From tcpm-bounces@ietf.org Tue Jun 13 20:06:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIuJ-0002Yt-JT; Tue, 13 Jun 2006 20:06:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqItt-0002PW-MX for tcpm@ietf.org; Tue, 13 Jun 2006 20:06:25 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqIos-0002WI-Ah for tcpm@ietf.org; Tue, 13 Jun 2006 20:01:15 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 13 Jun 2006 17:01:14 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="1825122501:sNHT34349330" 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/8.12.11) with ESMTP id k5E01DYC024051; Tue, 13 Jun 2006 17:01:13 -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 k5E01DCU025489; Tue, 13 Jun 2006 17:01:13 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 17:01:13 -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] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Tue, 13 Jun 2006 17:01:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Thread-Index: AcaPOZtuaA4+Ce1KR9uNaJk7xLfUuwACqTwg From: "Barry Greene \(bgreene\)" To: "Joe Touch" , "Andrew Lange" X-OriginalArrivalTime: 14 Jun 2006 00:01:13.0177 (UTC) FILETIME=[A6462C90:01C68F45] DKIM-Signature: a=rsa-sha1; q=dns; l=990; t=1150243273; x=1151107273; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:RE=3A=20[tcpm]=20Joe=20Touch=3A=20[Tsvwg]=20new=20I-D=3A=20TCP=20Simple= 20AuthenticationOption; X=v=3Dcisco.com=3B=20h=3DOSK5kmqyYU2N8t/Tf3FIMxFIFxc=3D; b=Vn9wGRb34tNUHI+u1QwvfjVXkWvhrmPknkXUnwsTOI1/WteWCa958AKhIAjrZDeGBCf+rmDj lAY2M6E3DgX3ypNBYLery4LedNCY4sQlvb1q6MoEmwZ0G7y7H7PsdDQD; Authentication-Results: sj-dkim-4.cisco.com; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org, mallman@icir.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 > Those modifications are already underway or implemented in=20 > the primary protocol of interest (BGP). These modifications=20 > reflect (IMO) an error in protocol design: TCP connectivity=20 > was never intended to reflect path viability for routing.=20 > Interpreting TCP disconnects as a path failure - which is the=20 > only reason to flush the associated routes - is thus an error=20 > which it is appropriate to correct. But why is it your job to correct your perception of a design error that the operators have no desire to change?=20 Operators submitted their design and expectation requirements to three vendors. Those vendors went off, explored a variety of options, and came up with a proposal (draft-bonica-tcp-auth-04.txt). The Operators then said "good, make it happen."=20 Now all I'm seeing from all parts of the IETF is "this is the wrong way to do it cause it does not fit how we perceive the Internet to be operated." I'm puzzled. =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 13 20:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIzb-0007wG-Dt; Tue, 13 Jun 2006 20:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIza-0007wB-C2 for tcpm@ietf.org; Tue, 13 Jun 2006 20:12:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqIzZ-0003QF-0Q for tcpm@ietf.org; Tue, 13 Jun 2006 20:12:18 -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 k5E0BJ628303; Tue, 13 Jun 2006 17:11:19 -0700 (PDT) Message-ID: <448F5420.6060102@isi.edu> Date: Tue, 13 Jun 2006 17:11:12 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Barry Greene (bgreene)" Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: 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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org, mallman@icir.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="===============1067173660==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1067173660== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig218A9FA33C33FDC277FE6570" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig218A9FA33C33FDC277FE6570 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry Greene (bgreene) wrote: > =20 >=20 >> Those modifications are already underway or implemented in=20 >> the primary protocol of interest (BGP). These modifications=20 >> reflect (IMO) an error in protocol design: TCP connectivity=20 >> was never intended to reflect path viability for routing.=20 >> Interpreting TCP disconnects as a path failure - which is the=20 >> only reason to flush the associated routes - is thus an error=20 >> which it is appropriate to correct. >=20 > But why is it your job to correct your perception of a design error tha= t > the operators have no desire to change?=20 We're the standards community; if there's an error in one standard (BGP) that creates a problem for another (TCP/MD5 needing to rekey mid-session) then it is we who resolve that contradiction. > Operators submitted their design and expectation requirements to three > vendors. Those vendors went off, explored a variety of options, and cam= e > up with a proposal (draft-bonica-tcp-auth-04.txt). The Operators then > said "good, make it happen."=20 That's between vendors and operators; if you want the IETF involved, you need to expose that loop to the community as per below. > Now all I'm seeing from all parts of the IETF is "this is the wrong way= > to do it cause it does not fit how we perceive the Internet to be > operated." I'm puzzled. We're equally puzzled as to why IPsec isn't sufficient as an alternative, since this is precisely what it was designed to do. Perhaps that's because we haven't been presented with the operator's requirements - which, BTW, need to be in the form of _WHAT_ they need, not _HOW_ to accomplish it. We haven't been presented with that yet; to the extent that we have seen glimpses of their requirements, we still don't understand why a TCP solution is required, or if so why rekeying inband is required. Further, I'm personally puzzled at the use of time-based keys - which add a notion of time that TCP doesn't have (TCP has timeouts, not time), and are not how other rekeying systems work (e.g., IKE). Answers to those would be a start. Joe --------------enig218A9FA33C33FDC277FE6570 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 iD8DBQFEj1QgE5f5cImnZrsRAiD/AKDyQr3L30McOo4yjhIG9euHHuZJzgCgrfUu 87fx0HHotArq7r+vJeip9qM= =Gt1R -----END PGP SIGNATURE----- --------------enig218A9FA33C33FDC277FE6570-- --===============1067173660== 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 --===============1067173660==-- From tcpm-bounces@ietf.org Tue Jun 13 22:27:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqL64-0002xY-S4; Tue, 13 Jun 2006 22:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqL63-0002xT-Fd for tcpm@ietf.org; Tue, 13 Jun 2006 22:27:07 -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 1FqL61-0001aQ-R8 for tcpm@ietf.org; Tue, 13 Jun 2006 22:27:07 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2006 19:27:05 -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/8.12.11) with ESMTP id k5E2R44B003491; Tue, 13 Jun 2006 19:27:04 -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 k5E2R3Ca007186; Tue, 13 Jun 2006 19:27:04 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 19:27:03 -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] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Tue, 13 Jun 2006 19:26:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Thread-Index: AcaPRyw1nrdRPPFqR+G922/TiQgECAAAKhFA From: "Barry Greene \(bgreene\)" To: "Joe Touch" X-OriginalArrivalTime: 14 Jun 2006 02:27:03.0704 (UTC) FILETIME=[05FEA180:01C68F5A] DKIM-Signature: a=rsa-sha1; q=dns; l=7578; t=1150252024; x=1151116024; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:RE=3A=20[tcpm]=20Joe=20Touch=3A=20[Tsvwg]=20new=20I-D=3A=20TCP=20Simple= 20AuthenticationOption; X=v=3Dcisco.com=3B=20h=3DOSK5kmqyYU2N8t/Tf3FIMxFIFxc=3D; b=PdlYxKNbSTB3BzRosIKzqr9Uj0mfUNw9FhIlLDW+X//x3qzBtr8bawm7BMnrP7f1339sdh8z k714VuAaRDuSys2qsp5jHNfGBxkm2ES1ad3VzA3izRnPuVAFDKfqBMzv; Authentication-Results: sj-dkim-3.cisco.com; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: tcpm@ietf.org, mallman@icir.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 Q. Why does BGP use TCP vs the link status? Cause of the ships in the night layering of the protocols. You want your IGP to have the ability to fail over links quickly with the BGP session staying up during the fail over. That is why you have iBGP meshed using the router's loopback address.=20 Is this broken? People who run the Internet seem to like it since it is the way we're gluing the whole Internet together. Q. Why isn't IPSEC used? Several reason. The re-keying and hitless issues I'll leave to Ron and the authors. My core reason is that IPSEC for a control plane protocol (OSPF, BGP, etc.) makes the router EXTREMELY vulnerable to a DOS attack. We're not talking about Mpps or Kpps attacks. We're talking about Hpps attacks that will have to bypass all the layered protection mechanisms built into a router to give it protection against this sort of abuse. draft-bonica-tcp-auth-04.txt allows the layered protection (combinations of classifications, policing, and hard queuing) to remain - doing the security checks as close to the conversion of photonic/electrical to packets as is feasible possible in hardware.=20 Q. Why do you need a timer in the solution? Telco meets. "Telco meets" are when to operators have to schedule a exact time to meet and configure equipment which touches each other. They are a pain to schedule and a huge OPEX cost to both parties. What the operators want to do is re-key and notify the other side that their new key is in place. At some time period later, the other side configures their new key. This could be days later.=20 The expense of the telco meets are one of the key reasons why you have MD5 keys on networks that are TEN YEARS OLD!=20 Q. Why do you need a hitless re-keying? Today many SPs have to report customer perceivable outage to their network to their telecoms regulator. Tomorrow with the continued convergence of services on top of IP, even the minor "non-perceivable - but measurable outages" will be required to be reported. So the seconds it takes to rebuilt, packets dropped, and recovery time it takes for OC192 connection's BGP session to be "re-key" is just too costly.=20 Do they want to re-key? Yes. Can they afford to re-key? Not today and definitely not tomorrow. Q. Why can't BGP Graceful Restart be used? When you look at the top SPs in the world (see below), you find that few to no SPs are planning on BGP Graceful Restart deployments. Some considered when looking at it as a security tool (after the April 2004 TCP vulnerability advisory). Most see no big operational savings on their networks - making it really tough to justify planning time, testing, pre-deployment, and maintenance windows to get it deployed.=20 So a basic requirement is no BGP Graceful Restart.=20 Next questions? Barry rank as org country s-c p-c a-c n 1 701 UUNET Technologies, Inc. US 6,940,288 177,765 19,386 2,371 2 174 Cogent Communications US 5,164,137 173,111 19,433 1,335 3 7018 AT&T WorldNet Services US 5,085,014 173,438 19,142 2,003 4 1239 Sprint US 5,058,048 173,686 19,240 1,697 5 2914 Verio, Inc. US 4,955,427 169,478 18,694 457 6 3561 Savvis US 4,794,705 164,726 18,030 540 7 209 Qwest US 4,790,916 164,036 17,920 1,161 8 703 UUNET Technologies, Inc. US 4,681,719 159,585 17,165 183 9 3549 Global Crossing US 4,659,580 162,217 17,711 741 10 3786 DACOM Corporation KR 4,649,565 160,775 17,347 270 11 2828 XO Communications US 4,649,129 160,414 17,420 472 12 702 MCI EMEA NL 4,640,429 160,222 17,229 542 13 4436 nLayer Communications, Inc. US 4,606,467 158,980 17,127 62 14 3356 Level 3 Communications, LLC US 4,606,335 158,963 17,120 1,290 15 4323 Time Warner Telecom US 4,606,335 158,963 17,120 605 16 3303 Swisscom Enterprise Solutions Ltd CH 4,606,335 158,963 17,120 582 17 6939 Hurricane Electric US 4,606,335 158,963 17,120 518 18 6461 Abovenet Communications, Inc US 4,606,335 158,963 17,120 495 19 13237 European Backbone of LambdaNet DE 4,606,335 158,963 17,120 436 20 8220 COLT Telecommunications - www.colt.net NL 4,606,335 158,963 17,120 408 21 1299 TeliaNet Global Network SE 4,606,335 158,963 17,120 379 22 6395 Broadwing Communications Services, Inc. US 4,606,335 158,963 17,120 369 23 6453 Teleglobe Inc CA 4,606,335 158,963 17,120 341 24 3320 Deutsche Telekom AG DE 4,606,335 158,963 17,120 338 25 7911 Williams Communications Group US 4,606,335 158,963 17,120 333 26 3491 Beyond The Network America, Inc. US 4,606,335 158,963 17,120 330 27 19151 WV FIBER LLC 4,606,335 158,963 17,120 296 28 286 KPN Internet Backbone AS NL 4,606,335 158,963 17,120 291 29 16150 Port80 AB, Sweden NL 4,606,335 158,963 17,120 281 30 2516 KDDI JP 4,606,335 158,963 17,120 280 30 6539 GT Group Telecom Services Corp. CA 4,606,335 158,963 17,120 280 =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Tuesday, June 13, 2006 5:11 PM > To: Barry Greene (bgreene) > Cc: Andrew Lange; tcpm@ietf.org; mallman@icir.org > Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple=20 > AuthenticationOption >=20 >=20 >=20 > Barry Greene (bgreene) wrote: > > =20 > >=20 > >> Those modifications are already underway or implemented in the=20 > >> primary protocol of interest (BGP). These modifications=20 > reflect (IMO)=20 > >> an error in protocol design: TCP connectivity was never=20 > intended to=20 > >> reflect path viability for routing. > >> Interpreting TCP disconnects as a path failure - which is the only=20 > >> reason to flush the associated routes - is thus an error=20 > which it is=20 > >> appropriate to correct. > >=20 > > But why is it your job to correct your perception of a design error=20 > > that the operators have no desire to change? >=20 > We're the standards community; if there's an error in one=20 > standard (BGP) that creates a problem for another (TCP/MD5=20 > needing to rekey > mid-session) then it is we who resolve that contradiction. >=20 > > Operators submitted their design and expectation=20 > requirements to three=20 > > vendors. Those vendors went off, explored a variety of options, and=20 > > came up with a proposal (draft-bonica-tcp-auth-04.txt). The=20 > Operators=20 > > then said "good, make it happen." >=20 > That's between vendors and operators; if you want the IETF=20 > involved, you need to expose that loop to the community as per below. >=20 > > Now all I'm seeing from all parts of the IETF is "this is the wrong=20 > > way to do it cause it does not fit how we perceive the=20 > Internet to be=20 > > operated." I'm puzzled. >=20 > We're equally puzzled as to why IPsec isn't sufficient as an=20 > alternative, since this is precisely what it was designed to=20 > do. Perhaps that's because we haven't been presented with the=20 > operator's requirements - which, BTW, need to be in the form=20 > of _WHAT_ they need, not _HOW_ to accomplish it. We haven't=20 > been presented with that yet; to the extent that we have seen=20 > glimpses of their requirements, we still don't understand why=20 > a TCP solution is required, or if so why rekeying inband is required. >=20 > Further, I'm personally puzzled at the use of time-based keys=20 > - which add a notion of time that TCP doesn't have (TCP has=20 > timeouts, not time), and are not how other rekeying systems=20 > work (e.g., IKE). >=20 > Answers to those would be a start. >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 10:17:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWBf-0005U3-Sp; Wed, 14 Jun 2006 10:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWBe-0005Tl-Su for tcpm@ietf.org; Wed, 14 Jun 2006 10:17:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWBe-0001hV-6L for tcpm@ietf.org; Wed, 14 Jun 2006 10:17:38 -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 k5EEGH617651; Wed, 14 Jun 2006 07:16:17 -0700 (PDT) Message-ID: <44901A2C.7000700@isi.edu> Date: Wed, 14 Jun 2006 07:16:12 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Barry Greene (bgreene)" Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: 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: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: tcpm@ietf.org, mallman@icir.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="===============1558825164==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1558825164== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig470446017984BDF6C945A6F7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig470446017984BDF6C945A6F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry Greene (bgreene) wrote: > Q. Why does BGP use TCP vs the link status? Cause of the ships in the > night layering of the protocols. You want your IGP to have the ability > to fail over links quickly with the BGP session staying up during the > fail over. That is why you have iBGP meshed using the router's loopback= > address.=20 Whether IGP fails over with BGP staying up depends on the protocols either uses to determine failure. There's no reason that link status alone would be used for BGP; indeed, layering suggests that a separate, tunable protocol would be appropriate to determine whether the other party is path-reachable rather than just link reachable. However, TCP isn't that protocol. As I noted before, that's a known error in design; there's nothing in TCP that is designed to ensure that a connection stays up if the other end is intermittently reachable. > Is this broken? Because it is based on an incorrect assumption, as noted above. > People who run the Internet seem to like it since it is > the way we're gluing the whole Internet together. That's not how we in the IETF define correctness. > Q. Why isn't IPSEC used? Several reason. The re-keying and hitless > issues I'll leave to Ron and the authors. My core reason is that IPSEC > for a control plane protocol (OSPF, BGP, etc.) makes the router > EXTREMELY vulnerable to a DOS attack. We're not talking about Mpps or > Kpps attacks. We're talking about Hpps attacks that will have to bypass= > all the layered protection mechanisms built into a router to give it > protection against this sort of abuse. draft-bonica-tcp-auth-04.txt > allows the layered protection (combinations of classifications, > policing, and hard queuing) to remain - doing the security checks as > close to the conversion of photonic/electrical to packets as is feasibl= e > possible in hardware.=20 IPsec hardware is available. Turning on any security leaves a device vulnerable to CPU load attacks; how is this different from TCP-Auth? Packets in TCP-Auth are filtered based on IP addresses and port pairs before being (expensively) authenticated. IPsec packets are filtered based on IP addresses and the SPI; the SPI is 32 bits that are arbitrary, wheras TCP's ports have only 16 arbitrary bits (source port). Is there some other technical reason that TCP-Auth is easier to filter thank IPsec? > Q. Why do you need a timer in the solution? Telco meets. "Telco meets" > are when to operators have to schedule a exact time to meet and > configure equipment which touches each other. They are a pain to > schedule and a huge OPEX cost to both parties. What the operators want > to do is re-key and notify the other side that their new key is in > place. At some time period later, the other side configures their new > key. This could be days later.=20 Why are operators involved in rekeying at all? > The expense of the telco meets are one of the key reasons why you have > MD5 keys on networks that are TEN YEARS OLD!=20 That's indicative of a number of things, including ignorance as to why rekeying is needed and apathy given the lack of ongoing attacks. > Q. Why do you need a hitless re-keying? Today many SPs have to report > customer perceivable outage to their network to their telecoms > regulator. Tomorrow with the continued convergence of services on top o= f > IP, even the minor "non-perceivable - but measurable outages" will be > required to be reported. So the seconds it takes to rebuilt, packets > dropped, and recovery time it takes for OC192 connection's BGP session > to be "re-key" is just too costly.=20 I agree with all this, but that is just why graceful restart BGP is the assumption. > Do they want to re-key? Yes. Can they afford to re-key? Not today and > definitely not tomorrow. >=20 >=20 > Q. Why can't BGP Graceful Restart be used? When you look at the top SPs= > in the world (see below), you find that few to no SPs are planning on > BGP Graceful Restart deployments. Some considered when looking at it as= > a security tool (after the April 2004 TCP vulnerability advisory). Most= > see no big operational savings on their networks - making it really > tough to justify planning time, testing, pre-deployment, and maintenanc= e > windows to get it deployed.=20 >=20 > So a basic requirement is no BGP Graceful Restart.=20 This is the most telling. So basically you're telling us that SPs are not willing to accept (existing) BGP graceful restart due to deployment costs and lack of operational savings. Exactly what is the basis for believing that they would accept TCP-Auth? It is extraordinarily more complex (than graceful restart + TCP-simple-auth). > Next questions? All stated above. So far, all you've done is confuse us as to why you want a solution at all (your last point), and why one of BGP/GR + TCP-simple-auth or BGP + IPsec/IKE is less acceptable than TCP-Auth. Joe --------------enig470446017984BDF6C945A6F7 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 iD8DBQFEkBosE5f5cImnZrsRAneTAJwJr/j78AoahY+p10kndJbJYgqeKQCg+ldZ OylZTs4EeVQMijvW1LGHLm0= =bH+9 -----END PGP SIGNATURE----- --------------enig470446017984BDF6C945A6F7-- --===============1558825164== 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 --===============1558825164==-- From tcpm-bounces@ietf.org Wed Jun 14 10:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWSL-0004fY-T5; Wed, 14 Jun 2006 10:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWSL-0004fQ-61; Wed, 14 Jun 2006 10:34:53 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWSJ-0005fz-M4; Wed, 14 Jun 2006 10:34:53 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 13D311BAC4D; Wed, 14 Jun 2006 16:23:48 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id F013110F89E; Wed, 14 Jun 2006 17:34:46 +0300 (EEST) In-Reply-To: <4489EFB6.3020309@isi.edu> References: <4489EFB6.3020309@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: From: Lars Eggert Date: Wed, 14 Jun 2006 17:34:45 +0300 To: tcpm@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [tcpm] Re: [Tsvwg] new I-D: TCP Simple Authentication Option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcpm@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1015897876==" Errors-To: tcpm-bounces@ietf.org --===============1015897876== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-189794046; protocol="application/pkcs7-signature" --Apple-Mail-17-189794046 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, (TSVWG BCC'ed.) There is an active discussion on the tcpm list about this ID (draft- touch-tcpm-tcp-simple-auth), draft-bonica-tcp-auth and the overall approach of replacing TCP-MD5 and/or securing BGP. The TSV ADs would like to ask the community to contribute to this discussion. There is a general agreement that we need to move away from TCP-MD5, but there isn't a clearly identified candidate mechanism that current users of TCP-MD5 should migrate to. We're trying to get a feeling on the view of the TSV community on this issue. Thanks, Lars PS: In order to not fragment the discussion, please respond on the tcpm list. -- Lars Eggert NEC Network Laboratories --Apple-Mail-17-189794046 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 hkiG9w0BCQUxDxcNMDYwNjE0MTQzNDQ2WjAjBgkqhkiG9w0BCQQxFgQUWRcAbdlaEXFa5EykjwGG O7yIgBMwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAMsWTHreJD7nvA2rCDhhgwI2aUDGgNAVmkfK2B2HaaC5KgPrr+bTYoFtFx69/TncvWJ98AUj q1KP8UfrKAxYqv0xPkHdTTztaWTjEJ4KcZ7s+gpZrKC/27B6gtMdWM9WE5p9M16FfP66+o78um3v rjrgJtTQd4EaKT4X1ZDxTxTMP302DW6adDk3dLtS0Ua1m0ljV0bUIfU7gZD0WE92BbbJ56xX8ltF aK7Qcx+6PJ4dgTHQxxtIP+Eeky07PTaHGEckzJ/PHhbdQ4eZIdEKgaGfwUSpA2PiewUgs97eRgqV f+KX19Lj9SKDHAg+ap3RX/ONfed8wZzOE2vX27yb6ucAAAAAAAA= --Apple-Mail-17-189794046-- --===============1015897876== 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 --===============1015897876==-- From tcpm-bounces@ietf.org Wed Jun 14 10:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWYm-0001bx-Bd; Wed, 14 Jun 2006 10:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWYl-0001aC-TI for tcpm@ietf.org; Wed, 14 Jun 2006 10:41:31 -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 1FqVdX-0004eH-BL for tcpm@ietf.org; Wed, 14 Jun 2006 09:42:23 -0400 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqVXt-0002mk-JP for tcpm@ietf.org; Wed, 14 Jun 2006 09:36:35 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Jun 2006 06:36:33 -0700 X-IronPort-AV: i="4.06,129,1149490800"; d="scan'208"; a="559232138:sNHT36009142" Received: from [172.25.42.216] ([172.25.42.216] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 09:36:31 -0400 Message-ID: <449010DD.40104@juniper.net> Date: Wed, 14 Jun 2006 09:36:29 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> <448F3D1E.1060309@isi.edu> In-Reply-To: <448F3D1E.1060309@isi.edu> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 13:36:31.0978 (UTC) FILETIME=[8C26D4A0:01C68FB7] X-Spam-Score: -2.0 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org, mallman@icir.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, I think that you are invoking a very old argument regarding BGP. That is, that a TCP connection failure should not be interpreted as a path failure and, therefore, should not cause routes to be withdrawn. You may or may not be right regarding this issue. However, the point is moot. For better or worse, that decision was made years ago and BGP became the infrastructure upon which interdomain routing is based. This isn't about to change any time soon. Given that BGP is what it is, we would do well to enhance TCP to support its current requirements. Ron Joe Touch wrote: > > Andrew Lange wrote: > >>Joe, Caitlin, >> >>What we do have to design protocols around is user requirements. We >>also have to design protocols with maximum flexibility and robustness. >>End users will use the protocols in ways we haven't predicted to meet >>requirements we don't yet know about. All TCP EXT AUTH does is provide >>a way to authenticate TCP sessions. It is radically more simple and >>easier to do this at the TCP layer than to implement something slightly >>different across a variety of higher-level routing protocols. > > > Those modifications are already underway or implemented in the primary > protocol of interest (BGP). These modifications reflect (IMO) an error > in protocol design: TCP connectivity was never intended to reflect path > viability for routing. Interpreting TCP disconnects as a path failure - > which is the only reason to flush the associated routes - is thus an > error which it is appropriate to correct. > > If that's not sufficient, it would be very useful to understand why > IPsec isn't more than sufficient to solve the user protocol requirements > here. > > If there are needs beyond the protocol level - e.g., anything involving > disgruntled employees fits in here - then it'd be useful to understand > why a protocol solution is necessary. > > Joe > > > >>On Jun 12, 2006, at 1:49 PM, Joe Touch wrote: >> >> >>> >>>Caitlin Bestler wrote: >>> >>>>Andrew Lange wrote: >>>> >>>>>Hi Joe, >>>>> >>>>>The main reason for the TCP extended auth proposal is the >>>>>ability to rollover keys without taking the session down. >>>>>Adding additional, more secure algorithms is a secondary goal. >>>>> >>>>>A key attack vector our customers are concerned about is the >>>>>disgruntled employee let go or other compromise of the key list. >>>>>They need to be able to change the keys without interrupting >>>>>the session and causing routing to suffer. Without this, a >>>>>new mechanism is not particularly useful. >>>>> >>>> >>>>Something about "disgruntled employee" sounds distinctly >>>>application domain to me. >>> >>>Yeah - and one would hope that wouldn't be frequent enough to design >>>protocols around either ;-) >>> >>>Joe >>> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 10:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWpb-0002Ak-2C; Wed, 14 Jun 2006 10:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWpa-00028N-7p for tcpm@ietf.org; Wed, 14 Jun 2006 10:58:54 -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 1FqWBK-0001B4-I0 for tcpm@ietf.org; Wed, 14 Jun 2006 10:17:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqW5n-0003HV-6G for tcpm@ietf.org; Wed, 14 Jun 2006 10:11:37 -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 k5EEAf616125; Wed, 14 Jun 2006 07:10:41 -0700 (PDT) Message-ID: <449018D7.7080501@isi.edu> Date: Wed, 14 Jun 2006 07:10:31 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> <448F3D1E.1060309@isi.edu> <449010DD.40104@juniper.net> In-Reply-To: <449010DD.40104@juniper.net> 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: 93e7fb8fef2e780414389440f367c879 Cc: tcpm@ietf.org, mallman@icir.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="===============1819481781==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1819481781== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F82C0B10DDE7098B3187B8F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F82C0B10DDE7098B3187B8F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ron Bonica wrote: > Joe, >=20 > I think that you are invoking a very old argument regarding BGP. That > is, that a TCP connection failure should not be interpreted as a path > failure and, therefore, should not cause routes to be withdrawn. >=20 > You may or may not be right regarding this issue. However, the point is= > moot. For better or worse, that decision was made years ago and BGP > became the infrastructure upon which interdomain routing is based. This= > isn't about to change any time soon. It is already changing, if it hasn't already - the relevant IDs are cited in my draft. > Given that BGP is what it is, we would do well to enhance TCP to suppor= t > its current requirements. Sorry, but that's nonsensical; you're asserting: - BGP is as it is; we can't change it - TCP needs to be modified I hope you can see why - if anything - the converse will always occur first. BGP isn't the only user of TCP. Joe >=20 > Ron >=20 > Joe Touch wrote: >> Andrew Lange wrote: >> >>> Joe, Caitlin, >>> >>> What we do have to design protocols around is user requirements. We >>> also have to design protocols with maximum flexibility and robustness= =2E=20 >>> End users will use the protocols in ways we haven't predicted to meet= >>> requirements we don't yet know about. All TCP EXT AUTH does is prov= ide >>> a way to authenticate TCP sessions. It is radically more simple and >>> easier to do this at the TCP layer than to implement something slight= ly >>> different across a variety of higher-level routing protocols. >> >> Those modifications are already underway or implemented in the primary= >> protocol of interest (BGP). These modifications reflect (IMO) an error= >> in protocol design: TCP connectivity was never intended to reflect pat= h >> viability for routing. Interpreting TCP disconnects as a path failure = - >> which is the only reason to flush the associated routes - is thus an >> error which it is appropriate to correct. >> >> If that's not sufficient, it would be very useful to understand why >> IPsec isn't more than sufficient to solve the user protocol requiremen= ts >> here. >> >> If there are needs beyond the protocol level - e.g., anything involvin= g >> disgruntled employees fits in here - then it'd be useful to understand= >> why a protocol solution is necessary. >> >> Joe >> >> >> >>> On Jun 12, 2006, at 1:49 PM, Joe Touch wrote: >>> >>> >>>> Caitlin Bestler wrote: >>>> >>>>> Andrew Lange wrote: >>>>> >>>>>> Hi Joe, >>>>>> >>>>>> The main reason for the TCP extended auth proposal is the >>>>>> ability to rollover keys without taking the session down. >>>>>> Adding additional, more secure algorithms is a secondary goal. >>>>>> >>>>>> A key attack vector our customers are concerned about is the >>>>>> disgruntled employee let go or other compromise of the key list. >>>>>> They need to be able to change the keys without interrupting >>>>>> the session and causing routing to suffer. Without this, a >>>>>> new mechanism is not particularly useful. >>>>>> >>>>> Something about "disgruntled employee" sounds distinctly >>>>> application domain to me. >>>> Yeah - and one would hope that wouldn't be frequent enough to design= >>>> protocols around either ;-) >>>> >>>> Joe >>>> >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm --------------enig8F82C0B10DDE7098B3187B8F 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 iD8DBQFEkBjbE5f5cImnZrsRAnRDAKC0gMq86bq6OyxP0gBvJTZxbJsFGQCaAn9R vnidHpNsDHbpO2+DzkLhk00= =8nHN -----END PGP SIGNATURE----- --------------enig8F82C0B10DDE7098B3187B8F-- --===============1819481781== 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 --===============1819481781==-- From tcpm-bounces@ietf.org Wed Jun 14 11:08:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWzD-0000Il-EI; Wed, 14 Jun 2006 11:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWzB-0000HR-Cw for tcpm@ietf.org; Wed, 14 Jun 2006 11:08:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWz9-0002S8-3M for tcpm@ietf.org; Wed, 14 Jun 2006 11:08:49 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 08:08:46 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208"; a="1825533521:sNHT35605942" 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/8.12.11) with ESMTP id k5EF8knn029972; Wed, 14 Jun 2006 08:08:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EF8j9s020499; Wed, 14 Jun 2006 08:08:46 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 08:08:45 -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] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Wed, 14 Jun 2006 08:08:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Thread-Index: AcaPwx5pMT9v993WQZKUpXO+Ca0P+gAAQV5Q From: "Barry Greene \(bgreene\)" To: "Joe Touch" , "Ron Bonica" X-OriginalArrivalTime: 14 Jun 2006 15:08:45.0329 (UTC) FILETIME=[6E493010:01C68FC4] DKIM-Signature: a=rsa-sha1; q=dns; l=658; t=1150297726; x=1151161726; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:RE=3A=20[tcpm]=20Joe=20Touch=3A=20[Tsvwg]=20new=20I-D=3A=20TCP=20Simple= 20AuthenticationOption; X=v=3Dcisco.com=3B=20h=3DOSK5kmqyYU2N8t/Tf3FIMxFIFxc=3D; b=OQc8FfCzzNnOi7zb7HQrYoFRfQ6y7cuwkEzhAFwlXeblvPlBxPuOi3/DCXj3yTCSZxRig+JG wzN+brmETBtXYI+mcVbFSUYAEee5MNAc6UyrRIELdbFk6Oy4oGrcxL4z; Authentication-Results: sj-dkim-4.cisco.com; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tcpm@ietf.org, mallman@icir.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 > > You may or may not be right regarding this issue. However,=20 > the point=20 > > is moot. For better or worse, that decision was made years=20 > ago and BGP=20 > > became the infrastructure upon which interdomain routing is based.=20 > > This isn't about to change any time soon. >=20 > It is already changing, if it hasn't already - the relevant=20 > IDs are cited in my draft. Where? I don't see that nor conversations which lead me to believe there is movement to push for a major change on massive consensus and working code with our SP routing protocol practice today. If there is some WG discussing this, please clue me in. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 11:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBG-00073Q-AX; Wed, 14 Jun 2006 11:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBF-00073L-Tg for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXBE-00039r-HO for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:17 -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 k5EFKx606861; Wed, 14 Jun 2006 08:20:59 -0700 (PDT) Message-ID: <44902955.9080006@isi.edu> Date: Wed, 14 Jun 2006 08:20:53 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Barry Greene (bgreene)" Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org, mallman@icir.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="===============0794976624==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0794976624== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFCBEEB77447C2A91B434266E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFCBEEB77447C2A91B434266E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry Greene (bgreene) wrote: > =20 >=20 >>> You may or may not be right regarding this issue. However,=20 >> the point=20 >>> is moot. For better or worse, that decision was made years=20 >> ago and BGP=20 >>> became the infrastructure upon which interdomain routing is based.=20 >>> This isn't about to change any time soon. >> It is already changing, if it hasn't already - the relevant=20 >> IDs are cited in my draft. >=20 > Where? I don't see that nor conversations which lead me to believe ther= e > is movement to push for a major change on massive consensus and working= > code with our SP routing protocol practice today. >=20 > If there is some WG discussing this, please clue me in. =2E.. This problem has already been addressed in extensions to BGP and BGP for MPLS, in a mechanism known as "graceful restart" [Re05][Sa04]. =2E.. [Re05] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS," draft-ietf-mpls-bgp-mpls-restart-05, (work in progress), Aug. 2005. [Sa04] Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful Restart Mechanism for BGP," draft-ietf-idr- restart-10 (work in progress), June 2004. The latter was an unfortunately old reference; there was a -11 version issued in May 2006, and a new version issued just 2 days ago: draft-ietf-idr-restart-12 Graceful Restart Mechanism for BGP Srihari Sangli idr 12-Jun-06 I encourage you to visit the IDR WG and ask them this question. Also OSPF as per below, if of interest. Some others missed in the first version of the draft (it was a -00 ;-): RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October 2005 ASCII INFORMATIONAL RFC3623 Graceful OSPF Restart J. Moy, P. Pillay-Esnault, A. Lindem November 2003 ASCII PROPOSED STANDARD RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. Leelanivas, Y. Rekhter, R. Aggarwal February 2003 ASCII PROPOSED STANDARD draft-holla-ospf-update-graceful-restart-01 Update to OSPF Graceful Restart procedure Ashok Holla individual 10-Mar-06 draft-ietf-ospf-ospfv3-graceful-restart-04 OSPFv3 Graceful Restart Padma Pillay-Esnault, Acee Lindem ospf 8-May-06 Joe --------------enigFCBEEB77447C2A91B434266E 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 iD8DBQFEkClVE5f5cImnZrsRAlfuAJ4j+aDdDOOOFsN3+rin/nCbLkDD4ACgioS6 wlNNLKmtnn0IpWl+J1UqIoQ= =8oDT -----END PGP SIGNATURE----- --------------enigFCBEEB77447C2A91B434266E-- --===============0794976624== 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 --===============0794976624==-- From tcpm-bounces@ietf.org Wed Jun 14 11:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBJ-00073v-HD; Wed, 14 Jun 2006 11:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBI-00073q-QI for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:20 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXBH-00039v-9m for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:20 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 791F41BAC4D; Wed, 14 Jun 2006 17:10:16 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 8DCE910F8EA; Wed, 14 Jun 2006 18:21:15 +0300 (EEST) In-Reply-To: <449010DD.40104@juniper.net> References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> <448F3D1E.1060309@isi.edu> <449010DD.40104@juniper.net> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <01F2A5F2-B9C8-4AC8-8528-EB453AA761CD@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Wed, 14 Jun 2006 18:21:13 +0300 To: Ron Bonica X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: tcpm@ietf.org, mallman@icir.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: , Content-Type: multipart/mixed; boundary="===============0323789283==" Errors-To: tcpm-bounces@ietf.org --===============0323789283== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-192582138; protocol="application/pkcs7-signature" --Apple-Mail-18-192582138 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Jun 14, 2006, at 16:36, Ron Bonica wrote: > Given that BGP is what it is, we would do well to enhance TCP to > support > its current requirements. I don't think this conclusion necessarily follows. Let me try to rephrase it: Given that BGP is what it is (and uses TCP in the way it does), we would do well to document a way to protect its TCP sessions that replaces TCP-MD5. (In the short term; in the long term, BGP may evolve.) There are several ways to protect BGP's TCP sessions. Not all of them require extensions to TCP. We need to pick one. That has proven difficult, because the different technical proposals are motivated by different sets of requirements. It would be good to come to a consensus on what requirements such a solution should fulfill. There is another complicating factor. BGP and TCP are both core protocols of the Internet. I can understand that from a BGP point of view a solution that replaces one non-BGP (i.e., TCP) extension with another is the preferred approach, because it minimizes modifications to BGP. However, the BGP folks need to realize that such approaches have a larger impact on TCP than others, and the TCP folks are likewise rightfully conservative when it comes to changes to TCP. (Especially changes that are only relevant to a single application on top of TCP.) Note that I'm not ruling out a TCP-based solution at all. But I'd be much happier if we arrived at such a conclusion based on an open- minded analysis of the pros and cons of the various proposals. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-18-192582138 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 hkiG9w0BCQUxDxcNMDYwNjE0MTUyMTE0WjAjBgkqhkiG9w0BCQQxFgQUEMdj5WbxfVUkBCdPO/+W 5nO1MuAwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAFZjfXm/IW9Xtt1jO7FgtcoXkYRPqFbA9+hbYVpNo1oAqhAdjACikLIvUBeKQcFJZetvDSLj /2xni0wwM9bP9GNNnQMRIofJ92g4SXD5GAZaoEPxtpFOfoTynTCRUWGprMLAa5LJ+UXTYqNaeDue U9ufla0pdCPtzdDfa7ra2THU6h+nKkYfueApwQVajLRz4BUMcO9fSGnrK0KSX7xyeGfk3PT1YUCI Y8E5DlAZ12RSlnhWA5UnMSyyaQpUlc5hmPcQo0jtp7HpUBy4kBmT8UcDB+RFpINnzo0ScOYzRtIE +DfdqhWsp5dJDqLOC14ZCuBJEYxvtH/Z4uxlvfyQG+kAAAAAAAA= --Apple-Mail-18-192582138-- --===============0323789283== 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 --===============0323789283==-- From tcpm-bounces@ietf.org Wed Jun 14 11:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBG-00073Q-AX; Wed, 14 Jun 2006 11:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBF-00073L-Tg for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXBE-00039r-HO for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:17 -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 k5EFKx606861; Wed, 14 Jun 2006 08:20:59 -0700 (PDT) Message-ID: <44902955.9080006@isi.edu> Date: Wed, 14 Jun 2006 08:20:53 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Barry Greene (bgreene)" Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org, mallman@icir.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="===============0794976624==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0794976624== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFCBEEB77447C2A91B434266E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFCBEEB77447C2A91B434266E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry Greene (bgreene) wrote: > =20 >=20 >>> You may or may not be right regarding this issue. However,=20 >> the point=20 >>> is moot. For better or worse, that decision was made years=20 >> ago and BGP=20 >>> became the infrastructure upon which interdomain routing is based.=20 >>> This isn't about to change any time soon. >> It is already changing, if it hasn't already - the relevant=20 >> IDs are cited in my draft. >=20 > Where? I don't see that nor conversations which lead me to believe ther= e > is movement to push for a major change on massive consensus and working= > code with our SP routing protocol practice today. >=20 > If there is some WG discussing this, please clue me in. =2E.. This problem has already been addressed in extensions to BGP and BGP for MPLS, in a mechanism known as "graceful restart" [Re05][Sa04]. =2E.. [Re05] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS," draft-ietf-mpls-bgp-mpls-restart-05, (work in progress), Aug. 2005. [Sa04] Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful Restart Mechanism for BGP," draft-ietf-idr- restart-10 (work in progress), June 2004. The latter was an unfortunately old reference; there was a -11 version issued in May 2006, and a new version issued just 2 days ago: draft-ietf-idr-restart-12 Graceful Restart Mechanism for BGP Srihari Sangli idr 12-Jun-06 I encourage you to visit the IDR WG and ask them this question. Also OSPF as per below, if of interest. Some others missed in the first version of the draft (it was a -00 ;-): RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October 2005 ASCII INFORMATIONAL RFC3623 Graceful OSPF Restart J. Moy, P. Pillay-Esnault, A. Lindem November 2003 ASCII PROPOSED STANDARD RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. Leelanivas, Y. Rekhter, R. Aggarwal February 2003 ASCII PROPOSED STANDARD draft-holla-ospf-update-graceful-restart-01 Update to OSPF Graceful Restart procedure Ashok Holla individual 10-Mar-06 draft-ietf-ospf-ospfv3-graceful-restart-04 OSPFv3 Graceful Restart Padma Pillay-Esnault, Acee Lindem ospf 8-May-06 Joe --------------enigFCBEEB77447C2A91B434266E 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 iD8DBQFEkClVE5f5cImnZrsRAlfuAJ4j+aDdDOOOFsN3+rin/nCbLkDD4ACgioS6 wlNNLKmtnn0IpWl+J1UqIoQ= =8oDT -----END PGP SIGNATURE----- --------------enigFCBEEB77447C2A91B434266E-- --===============0794976624== 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 --===============0794976624==-- From tcpm-bounces@ietf.org Wed Jun 14 11:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBJ-00073v-HD; Wed, 14 Jun 2006 11:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXBI-00073q-QI for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:20 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXBH-00039v-9m for tcpm@ietf.org; Wed, 14 Jun 2006 11:21:20 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 791F41BAC4D; Wed, 14 Jun 2006 17:10:16 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 8DCE910F8EA; Wed, 14 Jun 2006 18:21:15 +0300 (EEST) In-Reply-To: <449010DD.40104@juniper.net> References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> <448F3D1E.1060309@isi.edu> <449010DD.40104@juniper.net> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <01F2A5F2-B9C8-4AC8-8528-EB453AA761CD@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Wed, 14 Jun 2006 18:21:13 +0300 To: Ron Bonica X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: tcpm@ietf.org, mallman@icir.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: , Content-Type: multipart/mixed; boundary="===============0323789283==" Errors-To: tcpm-bounces@ietf.org --===============0323789283== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-192582138; protocol="application/pkcs7-signature" --Apple-Mail-18-192582138 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Jun 14, 2006, at 16:36, Ron Bonica wrote: > Given that BGP is what it is, we would do well to enhance TCP to > support > its current requirements. I don't think this conclusion necessarily follows. Let me try to rephrase it: Given that BGP is what it is (and uses TCP in the way it does), we would do well to document a way to protect its TCP sessions that replaces TCP-MD5. (In the short term; in the long term, BGP may evolve.) There are several ways to protect BGP's TCP sessions. Not all of them require extensions to TCP. We need to pick one. That has proven difficult, because the different technical proposals are motivated by different sets of requirements. It would be good to come to a consensus on what requirements such a solution should fulfill. There is another complicating factor. BGP and TCP are both core protocols of the Internet. I can understand that from a BGP point of view a solution that replaces one non-BGP (i.e., TCP) extension with another is the preferred approach, because it minimizes modifications to BGP. However, the BGP folks need to realize that such approaches have a larger impact on TCP than others, and the TCP folks are likewise rightfully conservative when it comes to changes to TCP. (Especially changes that are only relevant to a single application on top of TCP.) Note that I'm not ruling out a TCP-based solution at all. But I'd be much happier if we arrived at such a conclusion based on an open- minded analysis of the pros and cons of the various proposals. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-18-192582138 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 hkiG9w0BCQUxDxcNMDYwNjE0MTUyMTE0WjAjBgkqhkiG9w0BCQQxFgQUEMdj5WbxfVUkBCdPO/+W 5nO1MuAwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAFZjfXm/IW9Xtt1jO7FgtcoXkYRPqFbA9+hbYVpNo1oAqhAdjACikLIvUBeKQcFJZetvDSLj /2xni0wwM9bP9GNNnQMRIofJ92g4SXD5GAZaoEPxtpFOfoTynTCRUWGprMLAa5LJ+UXTYqNaeDue U9ufla0pdCPtzdDfa7ra2THU6h+nKkYfueApwQVajLRz4BUMcO9fSGnrK0KSX7xyeGfk3PT1YUCI Y8E5DlAZ12RSlnhWA5UnMSyyaQpUlc5hmPcQo0jtp7HpUBy4kBmT8UcDB+RFpINnzo0ScOYzRtIE +DfdqhWsp5dJDqLOC14ZCuBJEYxvtH/Z4uxlvfyQG+kAAAAAAAA= --Apple-Mail-18-192582138-- --===============0323789283== 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 --===============0323789283==-- From tcpm-bounces@ietf.org Wed Jun 14 12:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnQ-0001IN-HB; Wed, 14 Jun 2006 12:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnL-00015h-US for tcpm@ietf.org; Wed, 14 Jun 2006 12:00:39 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXcD-0006IA-5i for tcpm@ietf.org; Wed, 14 Jun 2006 11:49:10 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Jun 2006 08:49:08 -0700 X-IronPort-AV: i="4.06,129,1149490800"; d="scan'208"; a="559266899:sNHT31726848" Received: from [172.25.42.216] ([172.25.42.216] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 11:49:07 -0400 Message-ID: <44902FF0.9000501@juniper.net> Date: Wed, 14 Jun 2006 11:49:04 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: <44902955.9080006@isi.edu> In-Reply-To: <44902955.9080006@isi.edu> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 15:49:07.0846 (UTC) FILETIME=[1237F260:01C68FCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tcpm@ietf.org, mallman@icir.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, I don't think that Graceful Restart will be available in call cases. For example, it is likely to be unavailable on eBGP sessions between providers and their customers. Ron Joe Touch wrote: > > Barry Greene (bgreene) wrote: > >> >> >> >>>>You may or may not be right regarding this issue. However, >>> >>>the point >>> >>>>is moot. For better or worse, that decision was made years >>> >>>ago and BGP >>> >>>>became the infrastructure upon which interdomain routing is based. >>>>This isn't about to change any time soon. >>> >>>It is already changing, if it hasn't already - the relevant >>>IDs are cited in my draft. >> >>Where? I don't see that nor conversations which lead me to believe there >>is movement to push for a major change on massive consensus and working >>code with our SP routing protocol practice today. >> >>If there is some WG discussing this, please clue me in. > > > ... > This problem has already been addressed in extensions to BGP and BGP > for MPLS, in a mechanism known as "graceful restart" [Re05][Sa04]. > ... > [Re05] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for > BGP with MPLS," draft-ietf-mpls-bgp-mpls-restart-05, (work > in progress), Aug. 2005. > > [Sa04] Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, > "Graceful Restart Mechanism for BGP," draft-ietf-idr- > restart-10 (work in progress), June 2004. > > The latter was an unfortunately old reference; there was a -11 version > issued in May 2006, and a new version issued just 2 days ago: > > draft-ietf-idr-restart-12 Graceful Restart Mechanism for BGP Srihari > Sangli idr 12-Jun-06 > > I encourage you to visit the IDR WG and ask them this question. Also > OSPF as per below, if of interest. > > Some others missed in the first version of the draft (it was a -00 ;-): > > RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October > 2005 ASCII INFORMATIONAL > > RFC3623 Graceful OSPF Restart J. Moy, P. Pillay-Esnault, A. Lindem > November 2003 ASCII PROPOSED STANDARD > > RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. > Leelanivas, Y. Rekhter, R. Aggarwal February 2003 ASCII PROPOSED > STANDARD > > draft-holla-ospf-update-graceful-restart-01 Update to OSPF Graceful > Restart procedure Ashok Holla individual 10-Mar-06 > > draft-ietf-ospf-ospfv3-graceful-restart-04 OSPFv3 Graceful Restart > Padma Pillay-Esnault, Acee Lindem ospf 8-May-06 > > Joe > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 12:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXng-0001rT-9x; Wed, 14 Jun 2006 12:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnI-0000ug-Dr for tcpm@ietf.org; Wed, 14 Jun 2006 12:00:36 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXiA-0006dk-NR for tcpm@ietf.org; Wed, 14 Jun 2006 11:55:20 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 08:55:18 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208"; a="1825565501:sNHT34840546" 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/8.12.11) with ESMTP id k5EFtHdb007615; Wed, 14 Jun 2006 08:55:17 -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 k5EFtHCU002497; Wed, 14 Jun 2006 08:55:17 -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); Wed, 14 Jun 2006 08:55:17 -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] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Wed, 14 Jun 2006 08:55:16 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801B633A2@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Thread-Index: AcaPxjeyvfgznR9PTnu0+MsPKEqfhgAArwyw From: "Anantha Ramaiah \(ananth\)" To: "Lars Eggert" , "Ron Bonica" X-OriginalArrivalTime: 14 Jun 2006 15:55:17.0699 (UTC) FILETIME=[EEAB0930:01C68FCA] DKIM-Signature: a=rsa-sha1; q=dns; l=2482; t=1150300517; x=1151164517; c=relaxed/simple; s=sjdkim4001; 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]=20Joe=20Touch=3A=20[Tsvwg]=20new=20I-D=3A=20TCP=20Simple= 20AuthenticationOption; X=v=3Dcisco.com=3B=20h=3DV2UOg4xuLVwT2+Vk0bnXMfVuGM4=3D; b=CLxEceFQe5pk3I9yimXqygs+bgwZkYMHYrZwy8FJyGNyr7BDfWjedvZoPYsNgUcEvKxm9bKQ wZN2JrJjzBKJvVsO+YErFSkN+rT44WE2kZKrlc0tB4I+AnodW1DAJGok; Authentication-Results: sj-dkim-4.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Joe Touch , tcpm@ietf.org, mallman@icir.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 Lars/Joe :=20 A quick observation : IMO we shouldn't tie the TCP MD5 replacement and/or key change requirements for BGP alone. The TCP MD5 option is also used, although less "agressively", by other protocols like LDP and MSDP as well. Whatever solution is going to be devised should benefit other riders on TCP as well. $0.02, -Anantha > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 > Sent: Wednesday, June 14, 2006 8:21 AM > To: Ron Bonica > Cc: tcpm@ietf.org; mallman@icir.org; Joe Touch > Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple=20 > AuthenticationOption >=20 > Hi, >=20 > On Jun 14, 2006, at 16:36, Ron Bonica wrote: > > Given that BGP is what it is, we would do well to enhance TCP to=20 > > support its current requirements. >=20 > I don't think this conclusion necessarily follows. Let me try=20 > to rephrase it: >=20 > Given that BGP is what it is (and uses TCP in the way it=20 > does), we would do well to document a way to protect its TCP=20 > sessions that replaces TCP-MD5. (In the short term; in the=20 > long term, BGP may evolve.) >=20 > There are several ways to protect BGP's TCP sessions. Not all=20 > of them require extensions to TCP. We need to pick one. >=20 > That has proven difficult, because the different technical=20 > proposals are motivated by different sets of requirements. It=20 > would be good to come to a consensus on what requirements=20 > such a solution should fulfill. >=20 > There is another complicating factor. BGP and TCP are both=20 > core protocols of the Internet. I can understand that from a=20 > BGP point of view a solution that replaces one non-BGP (i.e.,=20 > TCP) extension with another is the preferred approach,=20 > because it minimizes modifications to BGP. However, the BGP=20 > folks need to realize that such approaches have a larger=20 > impact on TCP than others, and the TCP folks are likewise=20 > rightfully conservative when it comes to changes to TCP. =20 > (Especially changes that are only relevant to a single=20 > application on top of TCP.) >=20 > Note that I'm not ruling out a TCP-based solution at all. But=20 > I'd be much happier if we arrived at such a conclusion based=20 > on an open- minded analysis of the pros and cons of the=20 > various proposals. >=20 > Lars > --=20 > Lars Eggert NEC Network=20 > Laboratories >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 12:04:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXrU-00068k-7r; Wed, 14 Jun 2006 12:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXrT-00067B-7q for tcpm@ietf.org; Wed, 14 Jun 2006 12:04:55 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXrR-0000LY-NM for tcpm@ietf.org; Wed, 14 Jun 2006 12:04:55 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7955E1BAC4D; Wed, 14 Jun 2006 17:53:50 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 8541710F97C; Wed, 14 Jun 2006 19:04:51 +0300 (EEST) In-Reply-To: <0C53DCFB700D144284A584F54711EC5801B633A2@xmb-sjc-21c.amer.cisco.com> References: <0C53DCFB700D144284A584F54711EC5801B633A2@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <3573B035-CD23-4F36-9D58-92B145ED064C@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Wed, 14 Jun 2006 19:04:49 +0300 To: "Anantha Ramaiah (ananth)" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: tcpm@ietf.org, mallman@icir.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: , Content-Type: multipart/mixed; boundary="===============1872704255==" Errors-To: tcpm-bounces@ietf.org --===============1872704255== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21-195198054; protocol="application/pkcs7-signature" --Apple-Mail-21-195198054 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 14, 2006, at 18:55, Anantha Ramaiah (ananth) wrote: > IMO we shouldn't tie the TCP MD5 replacement and/or key change > requirements for BGP alone. The TCP MD5 option is also used, although > less "agressively", by other protocols like LDP and MSDP as well. > Whatever solution is going to be devised should benefit other > riders on > TCP as well. Valid point. Let me rephrase >> (Especially changes that are only relevant to a single >> application on top of TCP.) as: Especially changes that are only relevant to a small number of applications and a very, very small number of overall TCP connections. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-21-195198054 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 hkiG9w0BCQUxDxcNMDYwNjE0MTYwNDUwWjAjBgkqhkiG9w0BCQQxFgQUdJYo3ti2p6zRemsS1oFn +FXNo+YwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAA4abOWyuNiZM40v+PIG8anzrU+eGqE8Px5GDlc1nsY/YXakh2U/cHhEqofFpBoP5sRYj+U6 rqJse9afZKRaLhYpc/jfktS6lMQzzHwvanfxlW5SeVsaUGZ87cgJM5xJ5jcHq98ebzKFwL9Q258c rKRLnuG3wCmEk9g6hMfbb1CjfnpXyQRgdR7Ng9WJwSG4Tpe8j8VYgKVC2NgdMv4Qt1wlmivhNUfQ Avr5r+OOXX7qpgLCpIs4lJfvCnKuK1ifwdcLs0hVicsnRes1FJETOWvfbSTRo8P4qpideyZSc29y b2BuCeFW0NVl4XWK+hFTt0sBl0PvGFkMFJZ/MWVk7PQAAAAAAAA= --Apple-Mail-21-195198054-- --===============1872704255== 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 --===============1872704255==-- From tcpm-bounces@ietf.org Wed Jun 14 12:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtP-0008BL-Vi; Wed, 14 Jun 2006 12:06:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtO-00083l-0w for tcpm@ietf.org; Wed, 14 Jun 2006 12:06:54 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXtM-0000gt-Hg for tcpm@ietf.org; Wed, 14 Jun 2006 12:06:54 -0400 Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8CA6C1BAC4D; Wed, 14 Jun 2006 17:55:47 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 8004B10F987; Wed, 14 Jun 2006 19:06:48 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <3573B035-CD23-4F36-9D58-92B145ED064C@netlab.nec.de> References: <0C53DCFB700D144284A584F54711EC5801B633A2@xmb-sjc-21c.amer.cisco.com> <3573B035-CD23-4F36-9D58-92B145ED064C@netlab.nec.de> Message-Id: From: Lars Eggert Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Wed, 14 Jun 2006 19:06:47 +0300 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Joe Touch , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.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="===============0189850978==" Errors-To: tcpm-bounces@ietf.org --===============0189850978== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22-195316021; protocol="application/pkcs7-signature" --Apple-Mail-22-195316021 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 14, 2006, at 19:04, Lars Eggert wrote: > Especially changes that are only relevant to a small number of > applications and a very, very small number of overall TCP connections. ^^^^^^^ fraction Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-22-195316021 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 hkiG9w0BCQUxDxcNMDYwNjE0MTYwNjQ4WjAjBgkqhkiG9w0BCQQxFgQUryGuX24HYo6UkA3t5SWD 9yaBFYcwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBACTZcyuyXc2danxbFqIGV1sAwj+ZBJgD077sg3owp58VYj8tA+zDfGbhDCicZSu/np6ZwqPd 8R6hdD+oWmlISIOtQ3YGTzENSOp+s25erKBpjIQs3t9VZ1OSYRrbYAqHMlkZv6Xca8vPOr2OxSUo Za+yMQmwcD92OnrYOSuGB5w3ULXXrWQBX8E5R/ZL7P1UDNGGaD5v/YUreCOKaEEyuHjYL7Pg76rt LWXLsCDLlmLvGm36U1y4VYjlWpgh2yHUVha1+ndRjkm0+TCUBLIuum6NU19ycmZ6Xqj3jZyzwpho eVz8XnfYlJjG8D/Bn/r6bl4fCGirhGRCzD7mgrl6yPcAAAAAAAA= --Apple-Mail-22-195316021-- --===============0189850978== 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 --===============0189850978==-- From tcpm-bounces@ietf.org Wed Jun 14 12:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtm-0008Nz-IG; Wed, 14 Jun 2006 12:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtl-0008Nu-Hr for tcpm@ietf.org; Wed, 14 Jun 2006 12:07:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXtk-0000lQ-5I for tcpm@ietf.org; Wed, 14 Jun 2006 12:07:17 -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 k5EG6t619070; Wed, 14 Jun 2006 09:06:55 -0700 (PDT) Message-ID: <44903419.3020404@isi.edu> Date: Wed, 14 Jun 2006 09:06:49 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: <44902955.9080006@isi.edu> <44902FF0.9000501@juniper.net> In-Reply-To: <44902FF0.9000501@juniper.net> 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: 36c793b20164cfe75332aa66ddb21196 Cc: tcpm@ietf.org, mallman@icir.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="===============1615570184==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1615570184== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CF0F0FAED4C3653A13D873E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CF0F0FAED4C3653A13D873E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ron Bonica wrote: > Joe, >=20 > I don't think that Graceful Restart will be available in call cases. Fo= r > example, it is likely to be unavailable on eBGP sessions between > providers and their customers. Why? Why would TCP-Auth be accepted where graceful restart isn't? A technical argument would be useful here, but if this is a marketing prediction, it isn't. Joe >=20 > Joe Touch wrote: >> Barry Greene (bgreene) wrote: >> >>> >>> >>>>> You may or may not be right regarding this issue. However,=20 >>>> the point=20 >>>> >>>>> is moot. For better or worse, that decision was made years=20 >>>> ago and BGP=20 >>>> >>>>> became the infrastructure upon which interdomain routing is based. = >>>>> This isn't about to change any time soon. >>>> It is already changing, if it hasn't already - the relevant=20 >>>> IDs are cited in my draft. >>> Where? I don't see that nor conversations which lead me to believe th= ere >>> is movement to push for a major change on massive consensus and worki= ng >>> code with our SP routing protocol practice today. >>> >>> If there is some WG discussing this, please clue me in. >> >> ... >> This problem has already been addressed in extensions to BGP and BGP >> for MPLS, in a mechanism known as "graceful restart" [Re05][Sa04]. >> ... >> [Re05] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for= >> BGP with MPLS," draft-ietf-mpls-bgp-mpls-restart-05, (wor= k >> in progress), Aug. 2005. >> >> [Sa04] Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen,= >> "Graceful Restart Mechanism for BGP," draft-ietf-idr- >> restart-10 (work in progress), June 2004. >> >> The latter was an unfortunately old reference; there was a -11 version= >> issued in May 2006, and a new version issued just 2 days ago: >> >> draft-ietf-idr-restart-12 Graceful Restart Mechanism for BGP Srihar= i >> Sangli idr 12-Jun-06 >> >> I encourage you to visit the IDR WG and ask them this question. Also >> OSPF as per below, if of interest. >> >> Some others missed in the first version of the draft (it was a -00 ;-)= : >> >> RFC4167 Graceful OSPF Restart Implementation Report A. Lindem Octob= er >> 2005 ASCII INFORMATIONAL >> >> RFC3623 Graceful OSPF Restart J. Moy, P. Pillay-Esnault, A. Lindem >> November 2003 ASCII PROPOSED STANDARD >> >> RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M= =2E >> Leelanivas, Y. Rekhter, R. Aggarwal February 2003 ASCII PROPOSED= >> STANDARD >> >> draft-holla-ospf-update-graceful-restart-01 Update to OSPF Graceful >> Restart procedure Ashok Holla individual 10-Mar-06 >> >> draft-ietf-ospf-ospfv3-graceful-restart-04 OSPFv3 Graceful Restart >> Padma Pillay-Esnault, Acee Lindem ospf 8-May-06 >> >> Joe >> >> --------------enig2CF0F0FAED4C3653A13D873E 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 iD8DBQFEkDQZE5f5cImnZrsRAuJ5AJ454zTtVrRumHsptc83EpwZ1fawdQCggMhg AM1rpkSFHJt8I45lz021AVM= =2wlb -----END PGP SIGNATURE----- --------------enig2CF0F0FAED4C3653A13D873E-- --===============1615570184== 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 --===============1615570184==-- From tcpm-bounces@ietf.org Wed Jun 14 12:09:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXvd-0001il-LA; Wed, 14 Jun 2006 12:09:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXvc-0001ig-Tr for tcpm@ietf.org; Wed, 14 Jun 2006 12:09:12 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXvb-00015P-IK for tcpm@ietf.org; Wed, 14 Jun 2006 12:09:12 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 14 Jun 2006 09:09:00 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D35B42AF; Wed, 14 Jun 2006 09:08:59 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id AD62D2AE; Wed, 14 Jun 2006 09:08:59 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DTY55071; Wed, 14 Jun 2006 09:08:52 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E65B920501; Wed, 14 Jun 2006 09:08:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Wed, 14 Jun 2006 09:08:50 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F15765F8@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Thread-Index: AcaPxjszkF3/gg+PTX6haHQ0dboHAwABP5OA From: "Caitlin Bestler" To: "Lars Eggert" , "Ron Bonica" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061404; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230372E34343930333332312E303037452D412D; ENG=IBF; TS=20060614160901; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061404_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688EEB164I823363256-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Joe Touch , tcpm@ietf.org, mallman@icir.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 Lars Eggert wrote: > Hi, >=20 > On Jun 14, 2006, at 16:36, Ron Bonica wrote: >> Given that BGP is what it is, we would do well to enhance TCP to >> support its current requirements. >=20 > I don't think this conclusion necessarily follows. Let me try to > rephrase it:=20 >=20 > Given that BGP is what it is (and uses TCP in the way it > does), we would do well to document a way to protect its TCP > sessions that replaces TCP-MD5. (In the short term; in the long term, > BGP may evolve.)=20 >=20 > There are several ways to protect BGP's TCP sessions. Not all > of them require extensions to TCP. We need to pick one. >=20 I would phrase that as whether BGP's problems should be fixed in BGP or rather they should be fixed in TCP. To the best of my knowledge TCP-MD5 is not part of any standard stack. The TCP Option space is simply too limited for it to find it's way into a general deployment where it has to interoperate with other options (such as SACK). That means we essentially have a few platforms that have TCP-MD5 enabled and an overwhelming majority where they are not. This=20 forces variations in TCP stacks, divides auditing measures and forces TCP stacks for BGP to be implemented purely in software. IPSec is the preferred tool for this problem. By encouraging it's use, rather than carving out a special-use exemptions, we promote development of better IPSec solutions. If BGP has a problem with operational rekeying issues with IPSec then those issues should be raised about IPSec rather than defining a new security protocol. There is some merit to applying stare decisis here, and keeping TCP-MD5 functionality but allowing a new hash to be used. To the extent that we keep this funcitonality as an interesting footnote to the TCP roadmap (ignored by almost all implementations) then I think Joe's proposal is the correct way. TCP option space is a scarce resource. It should not be used for features that are better solves above or below the transport layer. Another option would be for BGP to SCTP and its authentication. SCTP control chunks are more extensible than TCP's option space, so the use of one extension does not automatically preclude the use of another. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 12:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXvq-0001mk-SJ; Wed, 14 Jun 2006 12:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXvp-0001mc-KA for tcpm@ietf.org; Wed, 14 Jun 2006 12:09:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXvo-00015u-7c for tcpm@ietf.org; Wed, 14 Jun 2006 12:09:25 -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 k5EG8A619338; Wed, 14 Jun 2006 09:08:10 -0700 (PDT) Message-ID: <44903464.6070504@isi.edu> Date: Wed, 14 Jun 2006 09:08:04 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: <0C53DCFB700D144284A584F54711EC5801B633A2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801B633A2@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: 34d35111647d654d033d58d318c0d21a Cc: Lars Eggert , tcpm@ietf.org, mallman@icir.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="===============0251310818==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0251310818== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC16CCA811A854FC2272E29F3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC16CCA811A854FC2272E29F3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Lars/Joe :=20 > A quick observation : >=20 > IMO we shouldn't tie the TCP MD5 replacement and/or key change > requirements for BGP alone. The TCP MD5 option is also used, although > less "agressively", by other protocols like LDP and MSDP as well. > Whatever solution is going to be devised should benefit other riders on= > TCP as well. Agreed, which is why LDP and MSDP may need similar graceful restart mechanisms. Joe >=20 > $0.02, > -Anantha >> -----Original Message----- >> From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 >> Sent: Wednesday, June 14, 2006 8:21 AM >> To: Ron Bonica >> Cc: tcpm@ietf.org; mallman@icir.org; Joe Touch >> Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple=20 >> AuthenticationOption >> >> Hi, >> >> On Jun 14, 2006, at 16:36, Ron Bonica wrote: >>> Given that BGP is what it is, we would do well to enhance TCP to=20 >>> support its current requirements. >> I don't think this conclusion necessarily follows. Let me try=20 >> to rephrase it: >> >> Given that BGP is what it is (and uses TCP in the way it=20 >> does), we would do well to document a way to protect its TCP=20 >> sessions that replaces TCP-MD5. (In the short term; in the=20 >> long term, BGP may evolve.) >> >> There are several ways to protect BGP's TCP sessions. Not all=20 >> of them require extensions to TCP. We need to pick one. >> >> That has proven difficult, because the different technical=20 >> proposals are motivated by different sets of requirements. It=20 >> would be good to come to a consensus on what requirements=20 >> such a solution should fulfill. >> >> There is another complicating factor. BGP and TCP are both=20 >> core protocols of the Internet. I can understand that from a=20 >> BGP point of view a solution that replaces one non-BGP (i.e.,=20 >> TCP) extension with another is the preferred approach,=20 >> because it minimizes modifications to BGP. However, the BGP=20 >> folks need to realize that such approaches have a larger=20 >> impact on TCP than others, and the TCP folks are likewise=20 >> rightfully conservative when it comes to changes to TCP. =20 >> (Especially changes that are only relevant to a single=20 >> application on top of TCP.) >> >> Note that I'm not ruling out a TCP-based solution at all. But=20 >> I'd be much happier if we arrived at such a conclusion based=20 >> on an open- minded analysis of the pros and cons of the=20 >> various proposals. >> >> Lars >> --=20 >> Lars Eggert NEC Network=20 >> Laboratories >> >> >> --------------enigC16CCA811A854FC2272E29F3 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 iD8DBQFEkDRkE5f5cImnZrsRAt4DAJ404N4h5xiODXdGTv6ke4ppWrN4egCgy5LY Hwqa+monex2GeQkdXzDngI4= =l7e0 -----END PGP SIGNATURE----- --------------enigC16CCA811A854FC2272E29F3-- --===============0251310818== 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 --===============0251310818==-- From tcpm-bounces@ietf.org Wed Jun 14 14:38:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaGU-0004KK-Qu; Wed, 14 Jun 2006 14:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaGU-0004KF-1Y for tcpm@ietf.org; Wed, 14 Jun 2006 14:38:54 -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 1FqaGT-00019C-J5 for tcpm@ietf.org; Wed, 14 Jun 2006 14:38:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k5EIcZI8019757; Wed, 14 Jun 2006 21:38:36 +0300 Date: Wed, 14 Jun 2006 21:38:35 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption In-Reply-To: <44903419.3020404@isi.edu> Message-ID: References: <44902955.9080006@isi.edu> <44902FF0.9000501@juniper.net> <44903419.3020404@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, mallman@icir.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 Wed, 14 Jun 2006, Joe Touch wrote: > Ron Bonica wrote: >> I don't think that Graceful Restart will be available in call cases. For >> example, it is likely to be unavailable on eBGP sessions between >> providers and their customers. > > Why? Why would TCP-Auth be accepted where graceful restart isn't? > > A technical argument would be useful here, but if this is a marketing > prediction, it isn't. Enabling Graceful Restart can cause black holes and loops under valid and rather common scenarios (e.g., power loss, forwarding plane crash). It has been designed in such a fashion that it cannot be enabled by default due to these bad effects, the users must know what they are doing. [1] As such, major router vendors do not enable graceful restart by default. It is not clear to me whether major router vendors enable graceful restart helper-mode by default. Helper mode is required for GR to be used. Hence, you have two dependencies: - you explicitly enable GR yourself and face the consequence, - your peers have enabled GR helper mode. >From that perspective, it seems natural that vendors and operators would prefer a self-contained solution. [1] I made an IETF Last call comment about this. The text was improved slightly in -11 but as the applicability and usefulness of GR seemed to be felt to be out of scope from interoperability perspective, these issues were not further discussed. -- 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 Wed Jun 14 14:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaW1-0000c3-EB; Wed, 14 Jun 2006 14:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaW0-0000by-W0 for tcpm@ietf.org; Wed, 14 Jun 2006 14:54:56 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqaVx-0002zs-Js for tcpm@ietf.org; Wed, 14 Jun 2006 14:54:56 -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 k5EIqb605463; Wed, 14 Jun 2006 11:52:37 -0700 (PDT) Message-ID: <44905AEF.60505@isi.edu> Date: Wed, 14 Jun 2006 11:52:31 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption References: <44902955.9080006@isi.edu> <44902FF0.9000501@juniper.net> <44903419.3020404@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, mallman@icir.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="===============0890554745==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0890554745== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08A0AB84BDB9FEEF8D4F696B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08A0AB84BDB9FEEF8D4F696B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given the questions about graceful restart, as well as the potential need to use TCP-SA for applications for which restart or handover would be difficult, would the following change suffice: >> TCP STATUS MUST allow TSAD entries for ongoing TCP connections ^^^^ (changed from MUST NOT) (i.e., not in the CLOSED state) to be modified. and append: (excepting fields that identify the connection, which MUST NOT be modified). This way the user level (user to TCP) can modify the TSAD entries while a connection is in progress. This allows out-of-band protocols (including timer mechanisms) to rekey the endpoints - or even change the algorithm or key length; all that happens is that packets in transit or using the previous key/alg/length fall on the floor for a while until both ends match. That 'while' should be short enough not to cause TCP to disconnect even with really poor coordination, AFAICT. IMO, this is a simple, contained modification, and pushes rekeying outside TCP (where it belongs, like initial key establishment IMO). Also, I do not see a need to add a key ID inband or OOB to make this happ= en. That's basically a one-word change to the requirements; it's a few paragraphs of change to the text, and it then allows TCP-SA to support dynamic rekeying. Thoughts? Joe --------------enig08A0AB84BDB9FEEF8D4F696B 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 iD8DBQFEkFrvE5f5cImnZrsRAp43AKCEV6IJQxVlqBGVFJG64Nu2mca0ZgCg0rew wWWKI0W86ltXWCjxy9HpZB0= =ADG3 -----END PGP SIGNATURE----- --------------enig08A0AB84BDB9FEEF8D4F696B-- --===============0890554745== 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 --===============0890554745==-- From tcpm-bounces@ietf.org Wed Jun 14 15:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaeN-0007AQ-78; Wed, 14 Jun 2006 15:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaeL-0007AE-Jg for tcpm@ietf.org; Wed, 14 Jun 2006 15:03:33 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqaeK-0003ue-8t for tcpm@ietf.org; Wed, 14 Jun 2006 15:03:33 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 14 Jun 2006 12:03:24 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 99BFC2B2; Wed, 14 Jun 2006 12:03:24 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 73C7A2B0; Wed, 14 Jun 2006 12:03:24 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DTZ43590; Wed, 14 Jun 2006 12:01:28 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id F417820501; Wed, 14 Jun 2006 12:01:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Wed, 14 Jun 2006 12:01:27 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1576653@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Thread-Index: AcaP4lcgwHEHBm1CRBaLnNO0jTIslwAAnL3A From: "Caitlin Bestler" To: "Pekka Savola" , "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061404; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230372E34343930354330312E303036362D412D; ENG=IBF; TS=20060614190325; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061404_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688E82F64I823593625-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, mallman@icir.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 Pekka Savola wrote: > On Wed, 14 Jun 2006, Joe Touch wrote: >> Ron Bonica wrote: >>> I don't think that Graceful Restart will be available in call cases. >>> For example, it is likely to be unavailable on eBGP sessions between >>> providers and their customers. >>=20 >> Why? Why would TCP-Auth be accepted where graceful restart isn't? >>=20 >> A technical argument would be useful here, but if this is a marketing >> prediction, it isn't. >=20 > Enabling Graceful Restart can cause black holes and loops > under valid and rather common scenarios (e.g., power loss, > forwarding plane crash). It has been designed in such a > fashion that it cannot be enabled by default due to these bad > effects, the users must know what they are doing. [1] >=20 > As such, major router vendors do not enable graceful restart > by default. It is not clear to me whether major router > vendors enable graceful restart helper-mode by default. > Helper mode is required for GR to be used. >=20 > Hence, you have two dependencies: > - you explicitly enable GR yourself and face the consequence, > - your peers have enabled GR helper mode. >=20 Is there any reason why re-keying a TCP-Auth connection is more graceful than simply migrating the session to a new connection with a different key and then closing the old connection? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 16:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqbwg-0006Im-6c; Wed, 14 Jun 2006 16:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqbwf-0006Ih-2z for tcpm@ietf.org; Wed, 14 Jun 2006 16:26:33 -0400 Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqbwc-0005xq-Oc for tcpm@ietf.org; Wed, 14 Jun 2006 16:26:33 -0400 Received: from [128.251.10.129] ([128.251.10.129]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id k5EKQQB3031149; Wed, 14 Jun 2006 15:26:26 -0500 In-Reply-To: <20060613225040.8EB0B423895@lawyers.icir.org> References: <20060613225040.8EB0B423895@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FF70B77-B76B-4185-8AF7-76A2712C498F@alcatel.com> Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Wed, 14 Jun 2006 13:26:22 -0700 To: mallman@icir.org X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Hi Mark, I'll try to answer your questions below. On Jun 13, 2006, at 3:50 PM, Mark Allman wrote: > > Andrew- > > As a still-puzzled observer... > >> What we do have to design protocols around is user requirements. We >> also have to design protocols with maximum flexibility and >> robustness. >> End users will use the protocols in ways we haven't predicted to meet >> requirements we don't yet know about. All TCP EXT AUTH does is >> provide a way to authenticate TCP sessions. It is radically more >> simple and easier to do this at the TCP layer than to implement >> something slightly different across a variety of higher- level >> routing >> protocols. > > Isn't this shove-it-down-into-a-common-place-in-the-stack-such-that- > it- > is-"radically more simple easier" notion one of the reasons we > ended up > with IPsec at the network layer? And, don't routing protocols > generally > use IP (at least those that use TCP)? Typically, yes. There are some routing protocols (ISIS) that don't use and IP layer, but those are out of scope for this solution. We're targeting TCP-based routing protocols specifically here. > In the above you argue for generality. I buy that. But, why don't we > use the general notion that has been developed for hardening TCP/IP > traffic (IPsec)? Why should we do something different in this case? IPSec is certainly an option. There are a lot of good things about IPSec. But, there are some shortcomings which have prompted operators to ask for a simpler mechanism. Some of these are: o DOS vulnerability on existing hardware. We want to improve security without requiring a wholesale swap of all the router control planes out there. o Cannot support pre-shared key rollover with the session up. - Here some explanation may be required. Certificates aren't an option because of the root trust problem between operators. So psk mode would be used. Rollover of this psk is desired. We cannot do this with IKEv2, and can only do this with IKEv1 using a bit of a hole in the protocol between session rekeyings. o IPSec is _perceived_ to be very complex, difficult to configure and maintain. With TCP Auth we will have another tool in the toolbox. This will help us improve security across the 'net. It is not intended to be the only tool that can be used, just one that will be easy to deploy and raise the security wall that much higher. Andrew > allman > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 16:57:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcQi-0006hJ-SA; Wed, 14 Jun 2006 16:57:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcQi-0006hE-8i for tcpm@ietf.org; Wed, 14 Jun 2006 16:57:36 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqcQg-0000IS-S2 for tcpm@ietf.org; Wed, 14 Jun 2006 16:57:36 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 14 Jun 2006 13:57:20 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2E0F92B1; Wed, 14 Jun 2006 13:57:20 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id F37C12B4; Wed, 14 Jun 2006 13:57:19 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DTZ96880; Wed, 14 Jun 2006 13:57:14 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 28F2120501; Wed, 14 Jun 2006 13:57:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Wed, 14 Jun 2006 13:57:13 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1576684@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Thread-Index: AcaP8N/oZDrjnwOjTJ+by4Ta5gkVlQAAqlpQ From: "Caitlin Bestler" To: "Andrew Lange" , mallman@icir.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061404; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230382E34343930373642382E303035452D412D; ENG=IBF; TS=20060614205725; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061404_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688EA7BA09K5394044-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Andrew Lange wrote: > Hi Mark, >=20 > I'll try to answer your questions below. >=20 >=20 > On Jun 13, 2006, at 3:50 PM, Mark Allman wrote: >=20 >>=20 >> Andrew- >>=20 >> As a still-puzzled observer... >>=20 >>> What we do have to design protocols around is user requirements. We >>> also have to design protocols with maximum flexibility and >>> robustness. End users will use the protocols in ways we haven't >>> predicted to meet requirements we don't yet know about. All TCP >>> EXT AUTH does is provide a way to authenticate TCP sessions. It is >>> radically more simple and easier to do this at the TCP layer than >>> to implement something slightly different across a variety of >>> higher- level routing protocols. >>=20 >> Isn't this shove-it-down-into-a-common-place-in-the-stack-such-that- >> it- is-"radically more simple easier" notion one of the reasons we >> ended up with IPsec at the network layer? And, don't routing >> protocols generally use IP (at least those that use TCP)? >=20 > Typically, yes. There are some routing protocols (ISIS) that don't > use and IP layer, but those are out of scope for this solution. > We're targeting TCP-based routing protocols specifically here. >=20 >> In the above you argue for generality. I buy that. But, why don't >> we use the general notion that has been developed for hardening >> TCP/IP traffic (IPsec)? Why should we do something different in >> this case?=20 >=20 > IPSec is certainly an option. There are a lot of good things > about IPSec. But, there are some shortcomings which have > prompted operators to ask for a simpler mechanism. Some of these are: >=20 > o DOS vulnerability on existing hardware. We want to improve > security without requiring a wholesale swap of all the router > control planes out there. > o Cannot support pre-shared key rollover with the session up. > - Here some explanation may be required. Certificates aren't > an option because of the root trust problem between > operators. So psk mode would be used. Rollover of this psk > is desired. We cannot do this with IKEv2, and can only do > this with IKEv1 using a bit of a hole in the protocol between > session rekeyings. > o IPSec is _perceived_ to be very complex, difficult to > configure and maintain. >=20 > With TCP Auth we will have another tool in the toolbox. This > will help us improve security across the 'net. It is not > intended to be the only tool that can be used, just one that > will be easy to deploy and raise the security wall that much higher. >=20 Extra TCP Options are not "just another wrench" in the toolbox. If TCP-AUTH were ever to be truly treated as part of TCP then it would be a lot of extra work for all TCP implementations because its interoperability with all other TCP Options would have to be validated. The fact that it is a large option makes this problematic. One goal of standardization is to allow implementers to focus their efforts on an agreed set of techniques. The consensus on providing secure communications is IPSec. We should be encouraging high quality implementations of IPSec by steering application layers to use it. If there is a feature missing, such as pre-shared key rollover, then it should be improved in IPSec rather than=20 creating an entire parallel mechanism (which won't be generally implemented) just to add one feature for a very small set of applications. The same applies to the configuration and maintenance. It would be absurd for the IETF to require a certain level of configuration complexity in IPSec "for security" and then decide that said=20 procedures were too onerous for the routers to use. If the security is truly required then why make the routing system the weakest link? If it is not required, why burden all the other applications? In either case that should be discussed in a security forum, not a TCP forum. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 17:44:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAQ-0002Kx-Pb; Wed, 14 Jun 2006 17:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAP-0002KK-Nz for tcpm@ietf.org; Wed, 14 Jun 2006 17:44:49 -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 1Fqbrn-0005o4-4B for tcpm@ietf.org; Wed, 14 Jun 2006 16:21:31 -0400 Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fqbko-0001QI-VS for tcpm@ietf.org; Wed, 14 Jun 2006 16:14:20 -0400 Received: from [128.251.10.129] ([128.251.10.129]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k5EKEDKp024964; Wed, 14 Jun 2006 15:14:13 -0500 In-Reply-To: <448F3D1E.1060309@isi.edu> References: <54AD0F12E08D1541B826BE97C98F99F15763A7@NT-SJCA-0751.brcm.ad.broadcom.com> <448DD356.7000909@isi.edu> <7DB7C2A3-C354-423D-A772-6A6C2C515E8E@alcatel.com> <448F3D1E.1060309@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D08BCBA-A4DA-4733-8A90-E82D617DEE98@alcatel.com> Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option Date: Wed, 14 Jun 2006 13:14:08 -0700 To: Joe Touch X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tcpm@ietf.org, mallman@icir.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 Hi Joe, On Jun 13, 2006, at 3:33 PM, Joe Touch wrote: > > > Andrew Lange wrote: >> Joe, Caitlin, >> >> What we do have to design protocols around is user requirements. We >> also have to design protocols with maximum flexibility and >> robustness. >> End users will use the protocols in ways we haven't predicted to meet >> requirements we don't yet know about. All TCP EXT AUTH does is >> provide >> a way to authenticate TCP sessions. It is radically more simple and >> easier to do this at the TCP layer than to implement something >> slightly >> different across a variety of higher-level routing protocols. > > Those modifications are already underway or implemented in the primary > protocol of interest (BGP). These modifications reflect (IMO) an error > in protocol design: TCP connectivity was never intended to reflect > path > viability for routing. Interpreting TCP disconnects as a path > failure - > which is the only reason to flush the associated routes - is thus an > error which it is appropriate to correct. I would encourage you to participate in the routing research efforts related to long term improvements in the global routing architecture. > If that's not sufficient, it would be very useful to understand why > IPsec isn't more than sufficient to solve the user protocol > requirements > here. There is nothing about TCP Auth that precludes the use of IPSec. The TCP Auth mechanism simply provides an important enhancement to existing security options. There is clear demand from people who run networks for a simple, re-keyable authentication mechanism for routing protocols. This fills that niche. If an operator wants IPSec, with the tradeoffs that means, they can use it. I think we can all agree that IPSec is not the end-all be- all of security. It is a good tool to have in the toolset, but not a miracle-wrench that fits all applications. TCP Auth provides another tool for these applications. > If there are needs beyond the protocol level - e.g., anything > involving > disgruntled employees fits in here - then it'd be useful to understand > why a protocol solution is necessary. Protocols are designed to provide functions for networks operated by people. The imperfection of human nature and organization requires that protocols support that imperfection. Almost any aspect of security needs to look at the whole threat model and do what we can to mitigate it. Andrew > > Joe > > >> On Jun 12, 2006, at 1:49 PM, Joe Touch wrote: >> >>> >>> >>> Caitlin Bestler wrote: >>>> Andrew Lange wrote: >>>>> Hi Joe, >>>>> >>>>> The main reason for the TCP extended auth proposal is the >>>>> ability to rollover keys without taking the session down. >>>>> Adding additional, more secure algorithms is a secondary goal. >>>>> >>>>> A key attack vector our customers are concerned about is the >>>>> disgruntled employee let go or other compromise of the key list. >>>>> They need to be able to change the keys without interrupting >>>>> the session and causing routing to suffer. Without this, a >>>>> new mechanism is not particularly useful. >>>>> >>>> >>>> Something about "disgruntled employee" sounds distinctly >>>> application domain to me. >>> >>> Yeah - and one would hope that wouldn't be frequent enough to design >>> protocols around either ;-) >>> >>> Joe >>> > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 14 18:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdVt-0001dU-87; Wed, 14 Jun 2006 18:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdVs-0001dP-Be for tcpm@ietf.org; Wed, 14 Jun 2006 18:07:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqdVq-0003Yi-TX for tcpm@ietf.org; Wed, 14 Jun 2006 18:07:00 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2006 15:06:57 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208"; a="294867099:sNHT283120396" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5EM6vGI005427; Wed, 14 Jun 2006 15:06:57 -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 k5EM6vIs012324; Wed, 14 Jun 2006 15:06:57 -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.211); Wed, 14 Jun 2006 15:06: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] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Date: Wed, 14 Jun 2006 15:06:56 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5801B635D7@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Thread-Index: AcaPxjszkF3/gg+PTX6haHQ0dboHAwABP5OAAAoSn6A= From: "Anantha Ramaiah \(ananth\)" To: "Caitlin Bestler" , "Lars Eggert" , "Ron Bonica" X-OriginalArrivalTime: 14 Jun 2006 22:06:57.0054 (UTC) FILETIME=[DA1E93E0:01C68FFE] DKIM-Signature: a=rsa-sha1; q=dns; l=4087; t=1150322817; x=1151186817; c=relaxed/simple; s=sjdkim8001; 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]=20Joe=20Touch=3A=20[Tsvwg]=20new=20I-D=3A=20TCP=20SimpleA uthentication=20Option; X=v=3Dcisco.com=3B=20h=3D+cEOqpgS0fotMbxvqDPQCTdAhI4=3D; b=Ysu6gvxCTlfFzT6BTvk9m/fwWuzjwvs1jV3tIJDbQyXBNG5RigFGUGT90gzGCmlKKsW6r8md HZEixSyu+4E634rJrwLhxEMUuFGUaMvpXU0Ck/wS0wUQG4TLxfwzbxUH; Authentication-Results: sj-dkim-8.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org, mallman@icir.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 Just one comment inline... > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com]=20 > Sent: Wednesday, June 14, 2006 9:09 AM > To: Lars Eggert; Ron Bonica > Cc: Joe Touch; tcpm@ietf.org; mallman@icir.org > Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP=20 > SimpleAuthentication Option >=20 > Lars Eggert wrote: > > Hi, > >=20 > > On Jun 14, 2006, at 16:36, Ron Bonica wrote: > >> Given that BGP is what it is, we would do well to enhance TCP to=20 > >> support its current requirements. > >=20 > > I don't think this conclusion necessarily follows. Let me try to=20 > > rephrase it: > >=20 > > Given that BGP is what it is (and uses TCP in the way it does), we=20 > > would do well to document a way to protect its TCP sessions that=20 > > replaces TCP-MD5. (In the short term; in the long term, BGP may=20 > > evolve.) > >=20 > > There are several ways to protect BGP's TCP sessions. Not=20 > all of them=20 > > require extensions to TCP. We need to pick one. > >=20 >=20 > I would phrase that as whether BGP's problems should be fixed=20 > in BGP or rather they should be fixed in TCP. >=20 > To the best of my knowledge TCP-MD5 is not part of any=20 > standard stack. The TCP Option space is simply too limited=20 > for it to find it's way into a general deployment where it=20 > has to interoperate with other options (such as SACK). >=20 > That means we essentially have a few platforms that have=20 > TCP-MD5 enabled and an overwhelming majority where they are=20 > not. This forces variations in TCP stacks, divides auditing=20 > measures and forces TCP stacks for BGP to be implemented=20 > purely in software. >=20 > IPSec is the preferred tool for this problem. By encouraging=20 > it's use, rather than carving out a special-use exemptions,=20 > we promote development of better IPSec solutions. If BGP has=20 > a problem with operational rekeying issues with IPSec then=20 > those issues should be raised about IPSec rather than=20 > defining a new security protocol. >=20 > There is some merit to applying stare decisis here, and keeping > TCP-MD5 functionality but allowing a new hash to be used. To=20 > the extent that we keep this funcitonality as an interesting=20 > footnote to the TCP roadmap (ignored by almost all=20 > implementations) then I think Joe's proposal is the correct way. >=20 > TCP option space is a scarce resource. It should not be used=20 > for features that are better solves above or below the=20 > transport layer. TCP option space is limited is a well known thing. However this should not be a reason to preclude anyone from not inventing new TCP options. If the TCP option space is limited then let's fix it. [ There are atleast 3 proposals on table which needs to be discussed including the recent one from from Mark Allman to address the TCP option space expansion] There are a wide variety of applications riding on top of TCP and as the internet evolved new requirements began to crop up and it is not always easier to move to a newer transport protocol (nice thing to do but not always feasible). There keeps coming some generic requirements in terms of connection security, connection persistence, connection tuning etc., which warrants the need for newer TCP options. However in most cases these newer TCP options never make it to standards and end up being proprietary or some other poorer alternatives sought.. I don't have the complete list, but I have seen this happening.=20 But I also do understand that the TCP option space should not be exploited for doing things that are better done in other layers.=20 -Anantha=20 >=20 > Another option would be for BGP to SCTP and its authentication. > SCTP control chunks are more extensible than TCP's option=20 > space, so the use of one extension does not automatically=20 > preclude the use of another. >=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 Wed Jun 14 18:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe2x-0004kX-GZ; Wed, 14 Jun 2006 18:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe2v-0004kS-Oy for tcpm@ietf.org; Wed, 14 Jun 2006 18:41:09 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqe2u-0004st-6c for tcpm@ietf.org; Wed, 14 Jun 2006 18:41:09 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 14 Jun 2006 15:40:51 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id F2AB52AE; Wed, 14 Jun 2006 15:40:50 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A0E8A2AF; Wed, 14 Jun 2006 15:40:50 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DUA45779; Wed, 14 Jun 2006 15:40:27 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E7CB720503; Wed, 14 Jun 2006 15:40:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Date: Wed, 14 Jun 2006 15:40:26 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F15766B3@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Thread-Index: AcaPxjszkF3/gg+PTX6haHQ0dboHAwABP5OAAAoSn6AAA+HhwA== From: "Caitlin Bestler" To: "Anantha Ramaiah (ananth)" , "Lars Eggert" , "Ron Bonica" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061404; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343930384546392E303032302D412D; ENG=IBF; TS=20060614224053; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061404_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688E4FF90HW31695236-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tcpm@ietf.org, mallman@icir.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 Anantha Ramaiah (ananth) wrote: > Just one comment inline... >=20 >>=20 >> There is some merit to applying stare decisis here, and keeping >> TCP-MD5 functionality but allowing a new hash to be used. To the >> extent that we keep this funcitonality as an interesting footnote to >> the TCP roadmap (ignored by almost all >> implementations) then I think Joe's proposal is the correct way. >>=20 >> TCP option space is a scarce resource. It should not be used for >> features that are better solves above or below the transport layer. >=20 > TCP option space is limited is a well known thing. However > this should not be a reason to preclude anyone from not > inventing new TCP options. > If the TCP option space is limited then let's fix it. [ There > are atleast 3 proposals on table which needs to be discussed > including the recent one from from Mark Allman to address the > TCP option space expansion] >=20 > There are a wide variety of applications riding on top of TCP > and as the internet evolved new requirements began to crop up > and it is not always easier to move to a newer transport > protocol (nice thing to do but not always feasible). There > keeps coming some generic requirements in terms of connection > security, connection persistence, connection tuning etc., > which warrants the need for newer TCP options. However in > most cases these newer TCP options never make it to standards > and end up being proprietary or some other poorer > alternatives sought.. I don't have the complete list, but I > have seen this happening. >=20 > But I also do understand that the TCP option space should not > be exploited for doing things that are better done in other layers. >=20 It is not as though TCP options are harmless pass-throughs that have zero impact on TCP stacks. TCP-Auth, for example, breaks LSO because you cannot calculate the hash before the message is segmented. And you will not see TCP-Auth getting hardware support because it has to get in line behind IPSec. Transport options can indeed be somewhat specialized, but they should at least be solving transport problems. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jun 15 01:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqkia-0002Zb-8o; Thu, 15 Jun 2006 01:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqkiS-0002Vf-Lv for tcpm@ietf.org; Thu, 15 Jun 2006 01:48:28 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqkXl-0006TC-Ap for tcpm@ietf.org; Thu, 15 Jun 2006 01:37:29 -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 k5F5ak617655; Wed, 14 Jun 2006 22:36:47 -0700 (PDT) Message-ID: <4490F1E8.8030000@isi.edu> Date: Wed, 14 Jun 2006 22:36:40 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option References: <54AD0F12E08D1541B826BE97C98F99F15766B3@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F15766B3@NT-SJCA-0751.brcm.ad.broadcom.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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Lars Eggert , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.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="===============2078210212==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2078210212== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3606DC3E5B697C3A0BA716B0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3606DC3E5B697C3A0BA716B0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: > It is not as though TCP options are harmless pass-throughs that > have zero impact on TCP stacks. TCP-Auth, for example, breaks > LSO because you cannot calculate the hash before the message > is segmented. And you will not see TCP-Auth getting hardware > support because it has to get in line behind IPSec. >=20 > Transport options can indeed be somewhat specialized, but they > should at least be solving transport problems. Transport hardware can also be specialized, but should solve the needed transport problems. If you have a TCP implementation that supports TCP/MD5, TCP-SA, or TCP-Auth, then LSO hardware ought to support that option or disable LSO on those connections. Joe --------------enig3606DC3E5B697C3A0BA716B0 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 iD8DBQFEkPHoE5f5cImnZrsRAjhxAJwMvPxyVE+3xzr2tBINSfSSTqXkoACg1Qg+ l84t3QSZq+NoyRr00k9mFsg= =aKFk -----END PGP SIGNATURE----- --------------enig3606DC3E5B697C3A0BA716B0-- --===============2078210212== 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 --===============2078210212==-- From tcpm-bounces@ietf.org Thu Jun 15 12:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquKJ-0006oe-EQ; Thu, 15 Jun 2006 12:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquKI-0006oW-Gj for tcpm@ietf.org; Thu, 15 Jun 2006 12:04:10 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquKH-00061j-4E for tcpm@ietf.org; Thu, 15 Jun 2006 12:04:10 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 15 Jun 2006 09:03:57 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id DABAA2B0; Thu, 15 Jun 2006 09:03:56 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A4B1A2AE; Thu, 15 Jun 2006 09:03:56 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DUE93803; Thu, 15 Jun 2006 09:03:54 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 23F1A20501; Thu, 15 Jun 2006 09:03:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Date: Thu, 15 Jun 2006 09:03:53 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1576777@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Thread-Index: AcaQPcxf3EhynM75Q3i5nyn2AwCn8QAVbM0g From: "Caitlin Bestler" To: "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061506; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343931383336392E303039462D412D; ENG=IBF; TS=20060615160358; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061506_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688F5B6709K5897369-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Lars Eggert , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.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: > Caitlin Bestler wrote: >> It is not as though TCP options are harmless pass-throughs that have >> zero impact on TCP stacks. TCP-Auth, for example, breaks LSO because >> you cannot calculate the hash before the message is segmented. And >> you will not see TCP-Auth getting hardware support because it has to >> get in line behind IPSec.=20 >>=20 >> Transport options can indeed be somewhat specialized, but they should >> at least be solving transport problems. >=20 > Transport hardware can also be specialized, but should solve > the needed transport problems. If you have a TCP > implementation that supports TCP/MD5, TCP-SA, or TCP-Auth, > then LSO hardware ought to support that option or disable LSO on > those connections.=20 >=20 > Joe Correct. But proliferating options that serve no general purpose transport need only adds to the laundry list of things that must be checked. If these were solving true transport problems, even if specialized, that would be justifiable. Instead you have a small set of applications that are shoving their problem down into the transport layer where all other applications have to pay for them to at least the extent that more asterisks must be added to the spec sheets (All RFCs supported except ...). Clutter has costs, even when each item appears minor. My real problem here is twofold. First, accepting proposed options as benign on the assumption that they won't be implemented is a bad idea -- especially when the rationale smells of "it' easier to get rekeying from TCPM/TSVWG than from a IPSec group.". Secondly, this is not an "option". The post I was responding to seemed to imply that options should be fairly simple things for even an embedded stack to just 'pass through'. An auth "option" has a value that is calculated *after* the TCP payload is formed. And once rekeying is enabled it becomes an alternate stream within the TCP connection. Options that are phased in over time make sense, options that will never be implemented except by a distinct minority of stacks are a totally different matter. Taking such an option and making it *more* complex, and hence even less likely to ever be implemented outside of its niche, makes suggeseting a shift to several other strong alternatives (such as IPSec) look preferable. But at the minimum, we should do no more than allowing the hash algorithm to be updated along the lines of your alternate proposal. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jun 15 12:10:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquQT-0003cK-J4; Thu, 15 Jun 2006 12:10:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquQS-0003cF-2N for tcpm@ietf.org; Thu, 15 Jun 2006 12:10:32 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquQQ-0006c0-MR for tcpm@ietf.org; Thu, 15 Jun 2006 12:10:32 -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 k5FG9c617902; Thu, 15 Jun 2006 09:09:38 -0700 (PDT) Message-ID: <4491863B.2070307@isi.edu> Date: Thu, 15 Jun 2006 09:09:31 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option References: <54AD0F12E08D1541B826BE97C98F99F1576777@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1576777@NT-SJCA-0751.brcm.ad.broadcom.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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Lars Eggert , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.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="===============1629267831==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1629267831== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF0C0D2465D711D971B6302F3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0C0D2465D711D971B6302F3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: > Joe Touch wrote: >> Caitlin Bestler wrote: >>> It is not as though TCP options are harmless pass-throughs that have >>> zero impact on TCP stacks. TCP-Auth, for example, breaks LSO because >>> you cannot calculate the hash before the message is segmented. And >>> you will not see TCP-Auth getting hardware support because it has to >>> get in line behind IPSec.=20 >>> >>> Transport options can indeed be somewhat specialized, but they should= >>> at least be solving transport problems. >> >> Transport hardware can also be specialized, but should solve >> the needed transport problems. If you have a TCP >> implementation that supports TCP/MD5, TCP-SA, or TCP-Auth, >> then LSO hardware ought to support that option or disable LSO on >> those connections.=20 >> >> Joe >=20 > Correct. >=20 > But proliferating options that serve no general purpose transport > need only adds to the laundry list of things that must be checked. No disagreement here. My only issue is that LSO implementations necessarily support the options their upper stacks support. Otherwise you have a bad TCP implementation. LSO is not a 'standard' that we need to decide how to interoperate with; it certainly does, though, complicate LSO to add options, especially unless where absolutely necessary. =2E.. > Secondly, this is not an "option". The post I was responding to > seemed to imply that options should be fairly simple things for > even an embedded stack to just 'pass through'. An auth "option" > has a value that is calculated *after* the TCP payload is formed. > And once rekeying is enabled it becomes an alternate stream within > the TCP connection. It's a payload dependent option. There are some others (trailer checksum, although not widely used), while most are not. That's a useful distinction regarding the interaction between the software TCP and LSO support. (i.e., my post was just a clarification on LSO; I suspect we're in loud agreement otherwise) Joe --------------enigF0C0D2465D711D971B6302F3 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 iD8DBQFEkYY8E5f5cImnZrsRAlBZAJ9leSh4SsZaym/pI1T3QkbV3z6IewCfWHD3 KAZfzt9xt+QolarKeq86RPY= =w5NF -----END PGP SIGNATURE----- --------------enigF0C0D2465D711D971B6302F3-- --===============1629267831== 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 --===============1629267831==-- From tcpm-bounces@ietf.org Thu Jun 15 18:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0Qm-00036K-FI; Thu, 15 Jun 2006 18:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0Ql-000323-Gv for tcpm@ietf.org; Thu, 15 Jun 2006 18:35:15 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0Qk-0004Ng-5l for tcpm@ietf.org; Thu, 15 Jun 2006 18:35:15 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 15 Jun 2006 15:35:05 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1BE532AE; Thu, 15 Jun 2006 15:35:05 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D2B802AF; Thu, 15 Jun 2006 15:35:04 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DUG53902; Thu, 15 Jun 2006 15:35:02 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 33B4720501; Thu, 15 Jun 2006 15:35:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Date: Thu, 15 Jun 2006 15:35:01 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B3664279B@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption Thread-Index: AcaPRyw1nrdRPPFqR+G922/TiQgECAAAKhFAAGDLcBA= From: "Bora Akyol" To: "Barry Greene (bgreene)" , "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061508; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230332E34343931444631362E303031342D412D; ENG=IBF; TS=20060615223505; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061508_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688F3F1309K5976483-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org, mallman@icir.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 > Q. Why isn't IPSEC used? Several reason. The re-keying and=20 > hitless issues I'll leave to Ron and the authors. My core=20 > reason is that IPSEC for a control plane protocol (OSPF, BGP,=20 > etc.) makes the router EXTREMELY vulnerable to a DOS attack.=20 >=20 Barry (continuing the discussion in NANOG), Having done IPSEC/IKE code for quite a few years, I am as puzzled about why IPSEC does not meet the hitless upgrades/rekeying issues as everyone else out there. Using my VPN client, I can stay connected to my work VPN for 24-72 hours and never get disconnected. With a typical rekey being about 30 mins or so. I am also confused about why certificates in this environment are not a good solution instead of using preshared keys. It's not like we are trying to do PKI for every ant in the world. Oops, I used the dreaded P*I word ;) Even if we used a preshared key (secret), it would still be secure to an extent as the preshared key is only used to derive the symmetric keys that are used to actually secure the connection, which is much better than what TCP MD5 auth does. I think the only other reason on why IPSEC may not work in this scenario is possibly because of the equipment involved may not have an IPSEC/IKE protocol code. Hope all is well, Bora _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jun 15 20:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2F7-00044R-A2; Thu, 15 Jun 2006 20:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2F5-000421-JN for tcpm@ietf.org; Thu, 15 Jun 2006 20:31:19 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr2F4-00019K-8v for tcpm@ietf.org; Thu, 15 Jun 2006 20:31:19 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 15 Jun 2006 17:31:10 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C3CB82AF; Thu, 15 Jun 2006 17:31:10 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 9F4812AE; Thu, 15 Jun 2006 17:31:10 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DUG98954; Thu, 15 Jun 2006 17:30:50 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 865C820501; Thu, 15 Jun 2006 17:30:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Date: Thu, 15 Jun 2006 17:30:46 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B366427CC@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option Thread-Index: AcaQPcxf3EhynM75Q3i5nyn2AwCn8QAVbM0gABIi+WA= From: "Bora Akyol" To: "Caitlin Bestler" , "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006061508; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230372E34343931464134442E303032302D412D; ENG=IBF; TS=20060616003112; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006061508_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 688F24444I824290740-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Lars Eggert , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.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 > My real problem here is twofold. First, accepting proposed=20 > options as benign on the assumption that they won't be=20 > implemented is a bad idea -- especially when the rationale=20 > smells of "it' easier to get rekeying from TCPM/TSVWG than=20 > from a IPSec group.". Ahem, IPSEC already supports rekeying ;) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 16 13:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrHpf-0007XZ-SG; Fri, 16 Jun 2006 13:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrHpe-0007XU-Et for tcpm@ietf.org; Fri, 16 Jun 2006 13:10:06 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrHpc-0003Ot-Vi for tcpm@ietf.org; Fri, 16 Jun 2006 13:10:06 -0400 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id D45CD64508 for ; Fri, 16 Jun 2006 11:09:59 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tcpm@ietf.org From: Danny McPherson Date: Fri, 16 Jun 2006 11:10:02 -0600 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [tcpm] MSS & TCP Options 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, Given the discussions regarding TCP authentication and "Options" as of late, and a problem we've seen manifest itself under certain conditions "in the field", I'm hoping someone here might be able to help me clarify something. And please be patient, I'm far from being a TCP expert. In a nutshell, I think my question can be summed up like this (with a much more verbose set of observations trailing): Is there a _definitive source for how the Eff.snd.MSS value should be calculated when TCP Options are employed, and precisely what should be contained in an advertised MSS wrt TCP Options? It seems to me an ambiguity arises from the fact that some deployed implementations subtract the size of the TCP options in the MSS value they advertise, AND they implicitly expect the senders to do the same (e.g., as specified in RFC 2385 and RFC 2581). Therefore they do NOT dynamically calculate the Eff.snd.MSS to include options when sending a TCP segment. Other implementations (e.g., Linux, OpenBSD, NetBSD) do NOT include TCP options in the advertised MSS, but rather, calculate them on a per-segment basis as specified in RFC 1122. The latter of these two methods seems more appropriate, given that some options are per-segment (e.g., SACK & Window Scale) and therefore the receiver has no way of knowing which options it's peer will be sending. Not only does RFC 2385 (TCP MD5 Signature Option) and RFC 2581 suffer from this, so to do the two TCP authentication I-Ds being discussed. Section 12.4 of this I-D appears to have copied the relevant text directly from RFC 2385, and therefore is equally susceptible: http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt And section 4.4 - 4.6 of this I-D has no mention of the calculations at all. I'm a bit surprised but perhaps this would lead someone back to an RFC 1122 model, rather than diverging from that as RFC 2385 and RFC 2581 have done: http://tools.ietf.org/wg/tcpm/draft-touch-tcpm-tcp-simple-auth-00.txt Finally, one other point worth mentioning is that if the end stations don't agree on how to calculate the Eff.snd.MSS then PMTU doesn't really fix it, and therefore transactions between TCP senders that expect the sender to include TCP option size in the advertised MSS (and therefore don't calculate dynamically into the Eff.snd.MSS) value can still be affected. Unless I'm missing something there's a dire need here for a single definitive source on this, and all the TCP Options work should reference it as such. --- So, some more details... RFC 1122; 4.2.2.6 talks about this a bit: The maximum size of a segment that TCP really sends, the "effective send MSS," MUST be the smaller of the send MSS (which reflects the available reassembly buffer size at the remote host) and the largest size permitted by the IP layer: Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize where: * SendMSS is the MSS value received from the remote host, or the default 536 if no MSS option is received. * MMS_S is the maximum size for a transport-layer message that TCP may send. * TCPhdrsize is the size of the TCP header; this is normally 20, but may be larger if TCP options are to be sent. * IPoptionsize is the size of any IP options that TCP will pass to the IP layer with the current message. I think the description in RFC 1122 is itself a little misleading. The first paragraph says "the smaller of the send MSS and the largest size permitted by the IP layer", however, the formula provided clearly shows that the TCP header size must be subtracted from the send MSS to calculate the effective send MSS. For example: (ipmtu=1500 - sizeof tcp - sizeof ip) = 1460 1460+20 - (sizeof(tcp) +sizeof(md5 option)) = 1480 - 40 = 1440 But both RFC 2581 and 2385 disagree with the above - and some comments from Thomas Narten and Bob Braden many moons ago found in the thread here: http://tcp-impl.grc.nasa.gov/list/archive/1961.html "Likewise, a receiver has no way of knowing what options its peer will be sending (i.e., they could vary on a segment-by-segment basis), so it should not consider options when calculating the MSS value it advertises." -- Thomas Narten" After passing this question by Thomas Narten, he suggested he today might reword that to something like this (with which I agree): "A TCP receiver (at the TCP layer) needs to advertise how large a segment it is able to accept. A peer TCP MUST NOT send a segment (data + header + options) larger than this, because the receiver presumably doesn't have enough buffer space to actually hold the received packet. That would be very bad..." However, more from Thomas and the previously mentioned thread: "But, my read of the thread suggests its not 100% clear what the advertised MSS should contain. e.g, http://tcp-impl.grc.nasa.gov/list/archive/1962.html says: > So the recommended answer is: 65532 - 20 - 20 bytes should be > sent in an MSS option. > implying the MSS is not the segment size, but the segment size excluding the fixed TCP header. (That would be a fine definition too, but it is (obviously) critically important that everyone agree on what the definition is.)" --- Another reference point is from RFC2525, ``Known TCP Implementation Problems'', where problem 2.18 ("Options missing from TCP MSS calculation") says this: When a TCP determines how much data to send per packet, it calculates a segment size based on the MTU of the path. It must then subtract from that MTU the size of the IP and TCP headers in the packet. If IP options and TCP options are not taken into account correctly in this calculation, the resulting segment size may be too large. But actual calculation of the Eff.snd.mss isn't discussed. So, with that, comments, clues and pointers welcome... Thanks! -danny _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 16 14:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIoJ-00078P-UB; Fri, 16 Jun 2006 14:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIoI-00078G-HN for tcpm@ietf.org; Fri, 16 Jun 2006 14:12:46 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIoH-0007Ft-4E for tcpm@ietf.org; Fri, 16 Jun 2006 14:12:46 -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 k5GIBk618552; Fri, 16 Jun 2006 11:11:46 -0700 (PDT) Message-ID: <4492F4BF.10407@isi.edu> Date: Fri, 16 Jun 2006 11:13:19 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> In-Reply-To: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> 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: f66b12316365a3fe519e75911daf28a8 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="===============2002875480==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2002875480== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B35E9E519B13ECFE10872C8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B35E9E519B13ECFE10872C8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: >=20 > Folks, > Given the discussions regarding TCP authentication and "Options" > as of late, and a problem we've seen manifest itself under certain > conditions "in the field", I'm hoping someone here might be able to > help me clarify something. And please be patient, I'm far from > being a TCP expert. >=20 > In a nutshell, I think my question can be summed up like this (with > a much more verbose set of observations trailing): >=20 > Is there a _definitive source for how the Eff.snd.MSS value should > be calculated when TCP Options are employed, and precisely what > should be contained in an advertised MSS wrt TCP Options? =2E.. > And section 4.4 - 4.6 of this I-D has no mention of the calculations > at all. I'm a bit surprised but perhaps this would lead someone back > to an RFC 1122 model, rather than diverging from that as RFC > 2385 and RFC 2581 have done: >=20 > http://tools.ietf.org/wg/tcpm/draft-touch-tcpm-tcp-simple-auth-00.txt That's correct - no mention. The reason is that there is no reason to treat this option uniquely from other options regarding MSS. I agree it would be useful to remind readers of that. I don't agree that RFC 3285 overrides RFC 1122 on this point - it too just presents a reminder. RFC 2581 presents the MSS values differently, and I haven't verified if it overrides RFC 1122 on this point. 1122, IMO, states: - Eff.snd.mss is the size of the DATA that can be sent in a TCP segment so needs to subtract the headers and their options - the advertised MSS is the size of the entire packet that can be received and parsed by the receiver, and so includes all headers). Its equation: Eff.snd.MSS =3D min(SendMSS-20, MMS_S) - TCPhdrsize - IPoptionsize is equivalent to saying: Eff.snd.MSS =3D min(SendMSS, MMS_S+20) - TCPhdrsize - IPhdrsize where IPhrdsize =3D IP header (i.e., 20) and IP options SendMSS thus expresses the space used to receive the entire packet into, and includes headers, and it'the other side's MMS_R MMS_S is the largest IP payload assuming a fixed header of 20 bytes - that's why the 20 is added before subtracting out space for the options and other headers. ---- this seems to me to be why there's a difference between the 'send once' of MSS_R during connection setup (the buffer for the segment doensn't change size) vs. the per-segment calculation of eff.snd.MSS (it determines how much data goes in THIS segment). Joe --------------enig8B35E9E519B13ECFE10872C8 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 iD8DBQFEkvS/E5f5cImnZrsRAj8HAJ489+rFmknaDFNJMgS8aTH1gOf8TACg6Gjf XBK5FPxz4Pe+rBX19s5W/dQ= =l8lR -----END PGP SIGNATURE----- --------------enig8B35E9E519B13ECFE10872C8-- --===============2002875480== 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 --===============2002875480==-- From tcpm-bounces@ietf.org Fri Jun 16 15:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKn-0007vk-I2; Fri, 16 Jun 2006 15:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKR-0007Yl-KH; Fri, 16 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKKQ-0000ef-AF; Fri, 16 Jun 2006 15:50:03 -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 k5GJo2Rx030927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FrKKQ-0004rq-1F; Fri, 16 Jun 2006 15:50:02 -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: Fri, 16 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-05.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 : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : R. Stewart, M. Dalal Filename : draft-ietf-tcpm-tcpsecure-05.txt Pages : 25 Date : 2006-6-16 A recent study indicates that some types of TCP connections have an increased vulnerability to spoofed packet injection attacks than previously believed [SITW]. TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Note: Both [SITW] and [I-D.touch-tcp-antispoof] provide charts which can give the reader an idea as to the time it takes to penetrate an unprotected system. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by carefully crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document requires small modifications to the way TCP handles inbound segments that can reduce the probability of such an attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-05.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-tcpsecure-05.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-tcpsecure-05.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-6-16135452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-16135452.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 Fri Jun 16 19:37:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNsU-0007V2-Nd; Fri, 16 Jun 2006 19:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNsT-0007Uw-1l for tcpm@ietf.org; Fri, 16 Jun 2006 19:37:25 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrNsR-0002Y8-ME for tcpm@ietf.org; Fri, 16 Jun 2006 19:37:25 -0400 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id A7E896450B for ; Fri, 16 Jun 2006 17:37:18 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4492F4BF.10407@isi.edu> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <4492F4BF.10407@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B1B1776-8CEE-4A0B-94DC-BFA8DB1F672C@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Fri, 16 Jun 2006 17:37:18 -0600 To: tcpm@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the response Joe, comments inline... - -danny On Jun 16, 2006, at 12:13 PM, Joe Touch wrote: > > I don't agree that RFC 3285 overrides RFC 1122 on this point - it too > just presents a reminder. A reminder from what? RFC 1122 is unclear about how to derive the "advertised MSS" value, and the only other relevant text would be RFC 879 before that, which states: The MSS counts only data octets in the segment, it does not count the TCP header or the IP header. and even it says nothing about what to do with TCP/IP options. Section 4.3 of RFC 2385 states: As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation. RFC 2385 specifies that the TCP MD5 Signature Option is factored into the advertised MSS value - "as with other options that are added" - - what options and where is the formula for this defined? > RFC 2581 presents the MSS values differently, In particular, Section 2 definition of RMSS: RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the largest segment the receiver is willing to accept. This is the value specified in the MSS option sent by the receiver during connection startup. Or, if the MSS option is not used, 536 bytes [Bra89]. The size does not include the TCP/IP headers and options. RFC 2581 says TCP/IP header sizes and options are NOT in the MSS value advertised to the peer. > and I haven't verified if it overrides RFC 1122 on this point. 1122, > IMO, states: > > - Eff.snd.mss is the size of the DATA that can be sent in a TCP > segment > so needs to subtract the headers and their options Yes, I agree with this, but Eff.snd.MSS is not my concern IF we're consistent with how to calculate the advertised MSS. Because we're not some implementations factor option sizes while others aren't, and that's my concern. > - the advertised MSS is the size of the entire packet that can be > received and parsed by the receiver, and so includes all headers). > > Its equation: But where did you obtain this specific equation from as it relates to calculating "advertised MSS"? > Eff.snd.MSS = min(SendMSS-20, MMS_S) - TCPhdrsize - IPoptionsize And assuming this was taken from RFC 1122, it's actually: Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize However, this is talking about the Eff.snd.MSS, not the "Advertised MSS", which are very different. RFC 1122 doesn't clearly define how to calculate the "advertised MSS", which is where my concern arises. I was looking for a definitive answer or citation about which behavior is correct. > is equivalent to saying: > > Eff.snd.MSS = min(SendMSS, MMS_S+20) - TCPhdrsize - IPhdrsize > > where IPhrdsize = IP header (i.e., 20) and IP options > SendMSS thus expresses the space used to receive the entire packet > into, > and includes headers, and it'the other side's MMS_R > MMS_S is the largest IP payload assuming a fixed header of 20 bytes - > that's why the 20 is added before subtracting out space for the > options > and other headers. > > this seems to me to be why there's a difference between the 'send > once' > of MSS_R during connection setup (the buffer for the segment doensn't > change size) vs. the per-segment calculation of eff.snd.MSS (it > determines > how much data goes in THIS segment). But the problem that arises is this... One host interprets it as RFC 2385 specifies where it assumes the size of TCP/IP options were factored into the MSS received from the peer. As such, it never subtracts those option values when calculating the Eff.snd.MSS for that peer. The other host assumes that the remote host will factor the TCP/IP options values when calculating it's Eff.snd.MSS. As such, when options are employed there's a possibly that segments received from the remote host will exceed it's MMS_R. We're seeing this in a real deployment on two popular stacks, so there is clearly confusion. I was looking for a pointer that defines which behavior is correct for calculating the advertised MSS value. Thanks again for the response! - -danny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEk0CxVbIg27AGOxoRAggaAJ9JuvNBbOMzergGt+1pdnfWKXF83ACgv62d ernUtPFjvALrBeOFeBzEjv0= =DVPM -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 16 20:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrOEy-0000ho-FP; Fri, 16 Jun 2006 20:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrOEx-0000hj-PD for tcpm@ietf.org; Fri, 16 Jun 2006 20:00:39 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrOEw-0006Ud-BX for tcpm@ietf.org; Fri, 16 Jun 2006 20:00:39 -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 k5GNxg607171; Fri, 16 Jun 2006 16:59:42 -0700 (PDT) Message-ID: <4493464B.2080405@isi.edu> Date: Fri, 16 Jun 2006 17:01:15 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <4492F4BF.10407@isi.edu> <3B1B1776-8CEE-4A0B-94DC-BFA8DB1F672C@tcb.net> In-Reply-To: <3B1B1776-8CEE-4A0B-94DC-BFA8DB1F672C@tcb.net> 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: c54bc2f42d02429833c0ca4b8725abd7 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="===============0869174576==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0869174576== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2048DCAF57DC28DCCDC35BF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2048DCAF57DC28DCCDC35BF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: > Thanks for the response Joe, comments inline... >=20 > -danny >=20 > On Jun 16, 2006, at 12:13 PM, Joe Touch wrote: >>> >>> I don't agree that RFC 3285 overrides RFC 1122 on this point - it too= >>> just presents a reminder. >=20 > A reminder from what? That this option, like other options, affects MSS calculations. Failure to take that into account has consequences. =2E.. >>> RFC 2581 presents the MSS values differently, >=20 > In particular, Section 2 definition of RMSS: >=20 > RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS > is the size of the largest segment the receiver is willing to accept= =2E > This is the value specified in the MSS option sent by the receiver > during connection startup. Or, if the MSS option is not used, 536 > bytes [Bra89]. The size does not include the TCP/IP headers > and options. >=20 > RFC 2581 says TCP/IP header sizes and options are NOT in the > MSS value advertised to the peer. What it should be reporting is the size of the buffer into which it can accept a segment. 2581 implies that data and headers are in different locations, and that only data has limited space. That seems an oversight to me. >>> and I haven't verified if it overrides RFC 1122 on this point. 1122, >>> IMO, states: >>> >>> - Eff.snd.mss is the size of the DATA that can be sent in a TCP segme= nt >>> so needs to subtract the headers and their options >=20 > Yes, I agree with this, but Eff.snd.MSS is not my concern IF we're > consistent with how to calculate the advertised MSS. Because we're > not some implementations factor option sizes while others aren't, and > that's my concern. Understood. >=20 >>> - the advertised MSS is the size of the entire packet that can be >>> received and parsed by the receiver, and so includes all headers). >>> >>> Its equation: >=20 > But where did you obtain this specific equation from as it relates > to calculating "advertised MSS"? >=20 >>> Eff.snd.MSS =3D min(SendMSS-20, MMS_S) - TCPhdrsize - IPoptionsize >=20 > And assuming this was taken from RFC 1122, it's actually: >=20 > Eff.snd.MSS =3D min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize Yes. > However, this is talking about the Eff.snd.MSS, not the "Advertised MSS= ", > which are very different. RFC 1122 doesn't clearly define how to > calculate the "advertised MSS", which is where my concern arises. I wa= s > looking for a definitive answer or citation about which behavior is > correct. I agree; this is about the send side decision, which includes the headers= =2E >>> is equivalent to saying: >>> >>> Eff.snd.MSS =3D min(SendMSS, MMS_S+20) - TCPhdrsize - IPhdrsize >>> >>> where IPhrdsize =3D IP header (i.e., 20) and IP options >>> SendMSS thus expresses the space used to receive the entire packet in= to, >>> and includes headers, and it'the other side's MMS_R >=20 >>> MMS_S is the largest IP payload assuming a fixed header of 20 bytes -= >>> that's why the 20 is added before subtracting out space for the optio= ns >>> and other headers. >>> >>> this seems to me to be why there's a difference between the 'send onc= e' >>> of MSS_R during connection setup (the buffer for the segment doensn't= >>> change size) vs. the per-segment calculation of eff.snd.MSS (it >>> determines >>> how much data goes in THIS segment). >=20 > But the problem that arises is this... >=20 > One host interprets it as RFC 2385 specifies where it assumes the size = of > TCP/IP options were factored into the MSS received from the peer. As s= uch, > it never subtracts those option values when calculating the Eff.snd.MSS= > for that peer. >=20 > The other host assumes that the remote host will factor the TCP/IP opti= ons > values when calculating it's Eff.snd.MSS. As such, when options are > employed there's a possibly that segments received from the remote host= > will exceed it's MMS_R. >=20 > We're seeing this in a real deployment on two popular stacks, so there = is > clearly confusion. This appears to be caused by 2385, but may be a result of assuming that data and headers are in separate areas. Joe --------------enigD2048DCAF57DC28DCCDC35BF 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 iD8DBQFEk0ZLE5f5cImnZrsRAu6OAJ9gFCCza6FNj3K5sYrIX2s3EJHvawCeNVrd o7zYPueMPQLXJAf0W4dWEwE= =lw/k -----END PGP SIGNATURE----- --------------enigD2048DCAF57DC28DCCDC35BF-- --===============0869174576== 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 --===============0869174576==-- From tcpm-bounces@ietf.org Mon Jun 19 14:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsO2x-0006vq-Ji; Mon, 19 Jun 2006 14:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsO2v-0006rX-MI for tcpm@ietf.org; Mon, 19 Jun 2006 14:00:21 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsO2u-0005uf-Bp for tcpm@ietf.org; Mon, 19 Jun 2006 14:00:21 -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 k5JI0F28099306 for ; Mon, 19 Jun 2006 11:00:15 -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 710D277B4DC for ; Mon, 19 Jun 2006 14:00:13 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Smoke On the Water MIME-Version: 1.0 Date: Mon, 19 Jun 2006 14:00:13 -0400 Message-Id: <20060619180013.710D277B4DC@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [tcpm] request for agenda items 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="===============1812022845==" Errors-To: tcpm-bounces@ietf.org --===============1812022845== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- The TCPM meeting in Montreal is currently scheduled for Thu Jul/13 at 1300. Ted and I have started to fill out an agenda. So, if you have something to say that would benefit from face-to-face time now would be the time to let us know such that we can work everyone in. Send requests to tcpm-chairs@tools.ietf.org. Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEluYtWyrrWs4yIs4RAjsfAJ4qIF+TixQUbM48ugw0x2liNreOjACdFRDC BxzCRhXxux+vVlLw61XJykc= =fvL1 -----END PGP SIGNATURE----- --=_bOundary-- --===============1812022845== 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 --===============1812022845==-- From tcpm-bounces@ietf.org Mon Jun 19 16:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPuf-0001Td-08; Mon, 19 Jun 2006 15:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPmD-00009x-Sy for tcpm@ietf.org; Mon, 19 Jun 2006 15:51:14 -0400 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPm8-0000Zo-QH for tcpm@ietf.org; Mon, 19 Jun 2006 15:51:13 -0400 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 5DDEE345D8; Mon, 19 Jun 2006 14:51:06 -0500 (CDT) Received: from cceexcsp04.americas.cpqcorp.net ([16.81.1.18]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 14:50:51 -0500 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] draft-ietf-rddp-mpa-03.txt review request Date: Mon, 19 Jun 2006 14:50:51 -0500 Message-ID: In-Reply-To: <447EFFFD.1020603@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-ietf-rddp-mpa-03.txt review request Thread-Index: AcaFi4PBpoS7X4v3T7amv2TtSvGT/gORbN+A From: "Culley, Paul" To: "Randall Stewart" X-OriginalArrivalTime: 19 Jun 2006 19:50:51.0572 (UTC) FILETIME=[AB2DA740:01C693D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Randall: Regarding the case you describe below; it is my impression that it is an allowable (possibly common) practice in TCP to manage the cwnd in segments. RFC2581 includes some notes on how to deal with cwnd in segments in section 3.1. =20 Furthermore, when there is enough data to fill segments, I would expect that implementations do fill them completely. To avoid cwnd violations, I assume that it is allowed to not actually send a segment until the cwnd is large enough to fill one. Seems like partly filling segments due to a small cwnd would lead to un-necessary small packets, extra overhead etc., the same kind of thing that other RFCs advise against doing for other reasons (silly window etc.). I have not been able to find any suggestion that it is not legal to increase cwnd unless you fully fill it; if you can point me to the appropriate text in an RFC I am willing to be educated. So the issue that you raise below need not be a problem for MPA-aware TCP stacks. I agree that there are various reasons that a standard TCP stack can lose segmentation, even with Nagle disabled, and your example may be one of them. However even in those cases, the way that DDP/MPA is usually used will tend to have breaks in the data stream where the transmit buffers drain. This will tend to re-establish segmentation. Also, the MPA draft is clear that receivers MUST operate even when segmentation is not occurring. Paul R. Culley HP Fellow 281-514-5543 -----Original Message----- From: Randall Stewart [mailto:rrs@cisco.com]=20 Sent: Thursday, June 01, 2006 9:56 AM To: Joe Touch Joe/All: Ok, I have read through this thread.. quite late.. and have a question related to the above... I get how a retransmission will cause resegmentation... and mess up MPA.. but is there not another case that no one as brought up that happens more on the norm... Consider a MPA sender sending 512 byte blocks (I do this for convience almost any size will do).. and assume we have a LOT of these to send... say at least 10. Now lets start with an intial cwnd =3D 4380... Now we start sending are 512 byte blocks 1:----send(512)----> to wire 2:----send(512)----> to wire ... 8:----send(512)----> to wire 9:----send(512)----> XXXX 10:---send(512)----> At the XXXX above we would NOT send the whole thing on the wire.. instead you will get 284 bytes sent to fill the cwnd. When the first ACK comes back you will then get the rest+512 bytes out... This is a NORMAL non-retransmission scheme where this would happen on a regular basis in a LOT of different forms.. Would not this cause additional issues... now I am by far not a TCP expert... not unless you flip two letters and stick an S in front of it :-D But we have seen an issue like this with SCTP... where we have to allow a "slop" over the cwnd otherwise the cwnd never grows... TCP never had this problem.. since if there was just a bit of room it can re-segment and transmit just a small piece to fill the cwnd exactly.... It seems to me this is an additional issue that one will find with "standard" TCP stacks.. and for new stacks they build to do MPA they will run in to the issue that they stop at segment 8 (above).. and then when the sack arrives they can send there segment.. but this also means (at least IMO) they are NOT using the full cwnd.. and thus should NOT be allowed to grow it ... A rather interesting issue that they need to address (if they have not already).. I confess I have not read the MPA draft anytime recently... so they may have a work-around for this... Just some thoughts.. late though they are :-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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 16:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQSv-00067O-KG; Mon, 19 Jun 2006 16:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQSt-000642-Fc for tcpm@ietf.org; Mon, 19 Jun 2006 16:35:19 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQI2-0007Bj-IA for tcpm@ietf.org; Mon, 19 Jun 2006 16:24:08 -0400 Received: from [24.120.149.181] (unknown [10.0.12.102]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 36217142E5 for ; Mon, 19 Jun 2006 16:23:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060619131628.611e5ffd@localhost> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 14:23:55 -0600 To: tcpm@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Jun 19, 2006, at 2:16 PM, Kevin Lahey wrote: > On Fri, 16 Jun 2006 11:10:02 -0600 > Danny McPherson wrote: > >> Is there a _definitive source for how the Eff.snd.MSS value should >> be calculated when TCP Options are employed, and precisely what >> should be contained in an advertised MSS wrt TCP Options? >> >> It seems to me an ambiguity arises from the fact that some >> deployed implementations subtract the size of the TCP options in >> the MSS value they advertise, AND they implicitly expect the >> senders to do the same (e.g., as specified in RFC 2385 and RFC >> 2581). Therefore they do NOT dynamically calculate the >> Eff.snd.MSS to include options when sending a TCP segment. > > Section 2.18 of RFC2525 discusses exactly this issue, not that I'd > call that a definitive answer.[*] Yep, I think I cited this in an email in an earlier thread. > If we're to take TCP options into account when calculating the MSS > option, what do we do about negotiated options like timestamps? > Should > we not take them into account when sending the first SYN, but take > them > into account when acknowledging a SYN (when we know that both sides > support them)? It seems that way lies madness. I agree, hence my opinion is that options should NOT be included in the advertised MSS and should always be calculated per-segment when sending (Eff.snd.MSS), and both sending and receiving TCP MUST be aware of this. Perhaps an I-D specifying this behavior more explicitly is in order? -danny _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 16:37:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQUp-0001xT-H0; Mon, 19 Jun 2006 16:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQSx-0005qg-ER for tcpm@ietf.org; Mon, 19 Jun 2006 16:35:23 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQGG-0006zQ-8n for tcpm@ietf.org; Mon, 19 Jun 2006 16:22:16 -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 k5JKJs604396; Mon, 19 Jun 2006 13:19:54 -0700 (PDT) Message-ID: <44970746.2010902@isi.edu> Date: Mon, 19 Jun 2006 13:21:26 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Culley, Paul" Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: 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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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="===============1678314681==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1678314681== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFFC6189F42A5CADEC98603E0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFFC6189F42A5CADEC98603E0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Culley, Paul wrote: > Randall: >=20 > Regarding the case you describe below; it is my impression that it is a= n > allowable (possibly common) practice in TCP to manage the cwnd in > segments. RFC2581 includes some notes on how to deal with cwnd in > segments in section 3.1. =20 Allowable, possibly common, but not required. The application layer must assume what TCP is allowed to do, NOT what an individual implementation of TCP happens to do (even if detected). There are no rules that TCP must be consistent in applying rounding of CWND to SMSS, or even that SMSS must be static over the life of a connection. > Furthermore, when there is enough data to fill segments, I would expect= > that implementations do fill them completely. To avoid cwnd violations= , > I assume that it is allowed to not actually send a segment until the > cwnd is large enough to fill one. Seems like partly filling segments > due to a small cwnd would lead to un-necessary small packets, extra > overhead etc., the same kind of thing that other RFCs advise against > doing for other reasons (silly window etc.). This assumption is based on how Nagle works; note that Nagle-ON means that a TCP will limit the partial outstanding (as yet un-ack'd) segments to one; it does NOT mean that only full segments will ever be sent. As noted in section 3.1 of RFC2581, there are equations that don't make sense if treated solely in terms of full segments. > I have not been able to find any suggestion that it is not legal to > increase cwnd unless you fully fill it; if you can point me to the > appropriate text in an RFC I am willing to be educated. That's correct; the issue isn't whether it needs to be filled, but that there is NO option at the application API in TCP to say "send only full segments". Again, this is a place where there appears to be an assumption in MPA that has been made many times before; I'll state the real issues again: there is NO guaranteed correlation between data boundaries in TCP's API (i.e., send/receive) and segments on the wire there is NO rule that a TCP which happens to break messages on API boundaries will continue to do so in the future, even if it has done so in the past > So the issue that you raise below need not be a problem for MPA-aware > TCP stacks. I agree that there are various reasons that a standard TCP= > stack can lose segmentation, even with Nagle disabled, and your example= > may be one of them. However even in those cases, the way that DDP/MPA > is usually used will tend to have breaks in the data stream where the > transmit buffers drain. This will tend to re-establish segmentation. That is a false conclusion. What a particular implementation will do regarding segmentation is up to that implementation. > Also, the MPA draft is clear that receivers MUST operate even when > segmentation is not occurring. This is fine, but to assume - or even expect - the optimization of boundary preservation is inappropriate; it is based on an implementation property that the protocol not only does not guarantee, it specifically allows. Joe > Paul R. Culley > HP Fellow > 281-514-5543 >=20 > -----Original Message----- > From: Randall Stewart [mailto:rrs@cisco.com]=20 > Sent: Thursday, June 01, 2006 9:56 AM > To: Joe Touch >=20 > Joe/All: >=20 > Ok, I have read through this thread.. quite late.. and have a question > related to the above... I get how a retransmission will cause > resegmentation... and mess up MPA.. but is there not another case that > no one as brought up that happens more on the norm... >=20 > Consider a MPA sender sending 512 byte blocks (I do this for convience > almost any size will do).. and assume we have a LOT of these to send...= > say at least 10. >=20 > Now lets start with an intial cwnd =3D 4380... >=20 > Now we start sending are 512 byte blocks >=20 > 1:----send(512)----> to wire > 2:----send(512)----> to wire > ... > 8:----send(512)----> to wire > 9:----send(512)----> XXXX > 10:---send(512)----> >=20 > At the XXXX above we would NOT send the whole thing on the wire.. > instead you will get 284 bytes sent to fill the cwnd. When the first AC= K > comes back you will then get the rest+512 bytes out... >=20 > This is a NORMAL non-retransmission scheme where this would happen on a= > regular basis in a LOT of different forms.. >=20 >=20 > Would not this cause additional issues... now I am by far not a TCP > expert... not unless you flip two letters and stick an S in front of it= > :-D >=20 > But we have seen an issue like this with SCTP... where we have to allow= > a "slop" over the cwnd otherwise the cwnd never grows... > TCP never had this problem.. since if there was just a bit of room it > can re-segment and transmit just a small piece to fill the cwnd > exactly.... >=20 > It seems to me this is an additional issue that one will find with > "standard" TCP stacks.. and for new stacks they build to do MPA they > will run in to the issue that they stop at segment 8 (above).. and then= > when the sack arrives they can send there segment.. but this also means= > (at least > IMO) they are NOT using the full cwnd.. and thus should NOT be allowed > to grow it ... >=20 > A rather interesting issue that they need to address (if they have not > already).. I confess I have not read the MPA draft anytime recently... > so they may have a work-around for this... >=20 > Just some thoughts.. late though they are :-D >=20 > R > -- > Randall Stewart > NSSTG - Cisco Systems Inc. > 803-345-0369 815-342-5222 (cell) >=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 --------------enigFFC6189F42A5CADEC98603E0 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 iD8DBQFElwdGE5f5cImnZrsRAmaVAKCMp569aD5ZGiY7YSZtvUAZ5m1pKACfchSA Iog1uF6NhYgoS1DIMccUxjI= =xBmQ -----END PGP SIGNATURE----- --------------enigFFC6189F42A5CADEC98603E0-- --===============1678314681== 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 --===============1678314681==-- From tcpm-bounces@ietf.org Mon Jun 19 16:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQkT-0000Be-2O; Mon, 19 Jun 2006 16:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQkR-0000BQ-EJ for tcpm@ietf.org; Mon, 19 Jun 2006 16:53:27 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQkO-0007dA-11 for tcpm@ietf.org; Mon, 19 Jun 2006 16:53:27 -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 k5JKqi612040; Mon, 19 Jun 2006 13:52:44 -0700 (PDT) Message-ID: <44970EF8.3060007@isi.edu> Date: Mon, 19 Jun 2006 13:54:16 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> In-Reply-To: <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> 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: 14582b0692e7f70ce7111d04db3781c8 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="===============1510811340==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1510811340== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD4A559079E074CB40678FAD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD4A559079E074CB40678FAD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: >=20 > On Jun 19, 2006, at 2:16 PM, Kevin Lahey wrote: >=20 >> On Fri, 16 Jun 2006 11:10:02 -0600 >> Danny McPherson wrote: >> >>> Is there a _definitive source for how the Eff.snd.MSS value should >>> be calculated when TCP Options are employed, and precisely what >>> should be contained in an advertised MSS wrt TCP Options? >>> >>> It seems to me an ambiguity arises from the fact that some >>> deployed implementations subtract the size of the TCP options in >>> the MSS value they advertise, AND they implicitly expect the >>> senders to do the same (e.g., as specified in RFC 2385 and RFC >>> 2581). Therefore they do NOT dynamically calculate the >>> Eff.snd.MSS to include options when sending a TCP segment. >> >> Section 2.18 of RFC2525 discusses exactly this issue, not that I'd >> call that a definitive answer.[*] >=20 > Yep, I think I cited this in an email in an earlier thread. >=20 >> If we're to take TCP options into account when calculating the MSS >> option, what do we do about negotiated options like timestamps? Shoul= d >> we not take them into account when sending the first SYN, but take the= m >> into account when acknowledging a SYN (when we know that both sides >> support them)? It seems that way lies madness. >=20 > I agree, hence my opinion is that options should NOT be included in > the advertised MSS IMO, the receiver should state what it's capable of receiving; this means the limit of its space is explicit, and let the sender decide how to make each transmitted segment fit... > and should always be calculated per-segment > when sending (Eff.snd.MSS),=20 Agreed. > and both sending and receiving TCP > MUST be aware of this. Agreed, though I come to an overall different conclusion: - advertised MSS should include all options and headers - it is the sender's responsibility to fit what it sends to that advertised limit That fits the 'be conservative in what you send, liberal in what you receive' rule. Liberal receiver =3D don't pick what's header and what's body, just state the buffer limit. Conservative sender =3D your job to fi= t to the receiver's limits. The receiver should, of course, truncate received segments at its advertised MSS to avoid buffer overruns. > Perhaps an I-D specifying this behavior more explicitly is in order? I'm not sure this needs a stand-alone I-D, or if we should collect such mods in a pending list somewhere and publish them when over some time/length threshold. FWIW, this was also revisited on the E2E list in 2005: http://mailman.postel.org/pipermail/end2end-interest/2005-April/004920.ht= ml Joe --------------enigBD4A559079E074CB40678FAD 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 iD8DBQFElw74E5f5cImnZrsRAu+6AKCP4Q8N17oE0HYk6mjLko6VmVmKlQCfTCwl yq88QpR6FGg6HTIABvJGsJs= =qPBY -----END PGP SIGNATURE----- --------------enigBD4A559079E074CB40678FAD-- --===============1510811340== 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 --===============1510811340==-- From tcpm-bounces@ietf.org Mon Jun 19 17:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQxp-0003Vs-CN; Mon, 19 Jun 2006 17:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQxn-0003Hd-C5 for tcpm@ietf.org; Mon, 19 Jun 2006 17:07:15 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQxm-0000ol-1D for tcpm@ietf.org; Mon, 19 Jun 2006 17:07:15 -0400 Received: from [24.120.149.181] (unknown [10.0.12.102]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id B9174142F3 for ; Mon, 19 Jun 2006 17:07:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44970EF8.3060007@isi.edu> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 15:07:02 -0600 To: tcpm@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 19, 2006, at 2:54 PM, Joe Touch wrote: >> >> I agree, hence my opinion is that options should NOT be included in >> the advertised MSS > > IMO, the receiver should state what it's capable of receiving; this > means the limit of its space is explicit, and let the sender decide > how > to make each transmitted segment fit... I'm fine with that as well, though with one slight concern, see below. > Agreed, though I come to an overall different conclusion: > > - advertised MSS should include all options and headers > - it is the sender's responsibility to fit what it sends > to that advertised limit Hrmm, so I guess at no point would the sender ever add an option to a segment that it wasn't aware of at connection setup time then, is that correct? > That fits the 'be conservative in what you send, liberal in what you > receive' rule. Liberal receiver = don't pick what's header and what's > body, just state the buffer limit. Conservative sender = your job > to fit > to the receiver's limits. Sure, though I think I could spin this to accommodate either model. > The receiver should, of course, truncate received segments at its > advertised MSS to avoid buffer overruns. Agreed, though with mismatched MTUs or the like it may lead to silent drops at some hop between the sender and receiver, no? Also, is it difficult to DoS harden such a model, or is this common practice today? > I'm not sure this needs a stand-alone I-D, or if we should collect > such > mods in a pending list somewhere and publish them when over some > time/length threshold. I'm happy with that, I just want it definitively documented and referencable some place. Where would such a collection of mods be contained today? > > FWIW, this was also revisited on the E2E list in 2005: > http://mailman.postel.org/pipermail/end2end-interest/2005-April/ > 004920.html Completely missed this thread when looking before asking, thanks for the pointer. - -danny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFElxH6VbIg27AGOxoRAhS3AJ9YYrykLAzsDZb/N3kHEzY7xNeV7gCfdYDE vcp4CeQlPLfKulXesLPjvdE= =I9e5 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 17:46:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRZb-0005ZC-7n; Mon, 19 Jun 2006 17:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRZY-0005Z3-Cc for tcpm@ietf.org; Mon, 19 Jun 2006 17:46:16 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRZT-0003iy-VW for tcpm@ietf.org; Mon, 19 Jun 2006 17:46:16 -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 k5JLjl623701; Mon, 19 Jun 2006 14:45:47 -0700 (PDT) Message-ID: <44971B67.9010703@isi.edu> Date: Mon, 19 Jun 2006 14:47:19 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@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: 73734d43604d52d23b3eba644a169745 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="===============1720022420==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1720022420== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF8CD51A92597422AE9B3F24F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF8CD51A92597422AE9B3F24F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: >=20 > On Jun 19, 2006, at 2:54 PM, Joe Touch wrote: >>>> >>>> I agree, hence my opinion is that options should NOT be included in >>>> the advertised MSS >>> >>> IMO, the receiver should state what it's capable of receiving; this >>> means the limit of its space is explicit, and let the sender decide h= ow >>> to make each transmitted segment fit... >=20 > I'm fine with that as well, though with one slight concern, > see below. >=20 >>> Agreed, though I come to an overall different conclusion: >>> >>> - advertised MSS should include all options and headers >>> - it is the sender's responsibility to fit what it sends >>> to that advertised limit >=20 > Hrmm, so I guess at no point would the sender ever add an > option to a segment that it wasn't aware of at connection setup > time then, is that correct? I don't see why that's a conclusion from the above. If the sender makes the decision of what options to send on a per-segment basis, it must fit to the advertised limit on a per-segment basis. The limit of what the receiver can buffer is the only thing here that doesn't change after connection setup; I don't see why it should, and it would be hard to coordinate a change if it did. =2E.. >>> The receiver should, of course, truncate received segments at its >>> advertised MSS to avoid buffer overruns. >=20 > Agreed, though with mismatched MTUs or the like it may lead > to silent drops at some hop between the sender and receiver, > no?=20 They already do (PMTU failures). > Also, is it difficult to DoS harden such a model, or is this > common practice today? I'm not sure what you mean - can you explain? >>> I'm not sure this needs a stand-alone I-D, or if we should collect su= ch >>> mods in a pending list somewhere and publish them when over some >>> time/length threshold. >=20 > I'm happy with that, I just want it definitively documented and > referencable some place. Where would such a collection of mods > be contained today? RFC 2525 is the closest thing, but it focused on implementation issues, not spec issues. I'm proposing that TCPM might keep a list of such mods... Joe --------------enigF8CD51A92597422AE9B3F24F 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 iD8DBQFElxtnE5f5cImnZrsRAiCIAJ0W/X47nqEsQfvmDTFQ8ISXj9rMzQCgxLnq md9FGGxffYcO42EPpju/DRo= =QipC -----END PGP SIGNATURE----- --------------enigF8CD51A92597422AE9B3F24F-- --===============1720022420== 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 --===============1720022420==-- From tcpm-bounces@ietf.org Mon Jun 19 19:24:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsT6A-0005Ek-TW; Mon, 19 Jun 2006 19:24:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsT69-0005Ef-6Q for tcpm@ietf.org; Mon, 19 Jun 2006 19:24:01 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsT67-0000Pu-Om for tcpm@ietf.org; Mon, 19 Jun 2006 19:24:01 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id k5JNE6pD026785; Mon, 19 Jun 2006 18:14:06 -0500 (CDT) In-Reply-To: <44970EF8.3060007@isi.edu> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 18:13:41 -0500 To: Joe Touch , Danny McPherson X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 *Sigh*. This topic keeps coming up, and it's really not that difficult. The MSS value that is put into the TCP MSS option does *not* include space for either TCP or IP options. You only adjust for the fixed IP and TPC headers. When sending a packet, you calculate Eff.snd.MSS, and in that calculation you do subtract off for the TCP and IP options that you know are going into the packet! -David Borman Here's my message from the last time this came up: > Subject: Re: [e2e] Question on MTU > Date: April 21, 2005 5:13:22 PM CDT > To: touch@isi.edu > Cc: end2end-interest@postel.org > > Joe, > > The "effective send MSS" takes into account options, but the MSS value > put into the TCP MSS option should not. In section 4.2.2.6 of RFC > 1122: > The MSS value to be sent in an MSS option must be less > than > or equal to: > > MMS_R - 20 > > where MMS_R is the maximum size for a transport-layer > message that can be received (and reassembled). TCP > obtains > MMS_R and MMS_S from the IP layer; see the generic call > GET_MAXSIZES in Section 3.4. > > And in section 3.3.2: > > There MUST be a mechanism by which the transport layer can > learn MMS_R, the maximum message size that can be > received and > reassembled in an IP datagram (see GET_MAXSIZES calls in > Section 3.4). If EMTU_R is not indefinite, then the > value of > MMS_R is given by: > > MMS_R = EMTU_R - 20 > > since 20 is the minimum size of an IP header. > > The receiver can't reliably predict what IP or TCP options the sender > is going to put into the packets, so it doesn't include them in the > MSS > option. The sender then does take those options into account when > calculating the "effective send MSS", because it knows exactly what > options are going into the packet. > > -David Borman ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 19:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTPD-0001ct-Fz; Mon, 19 Jun 2006 19:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTPC-0001cb-Ht for tcpm@ietf.org; Mon, 19 Jun 2006 19:43:42 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTPB-0002Hc-Ab for tcpm@ietf.org; Mon, 19 Jun 2006 19:43:42 -0400 Received: from [24.120.149.181] (unknown [10.0.12.102]) by gott.aa.arbor.net (Postfix) with ESMTP id 4921E143F6 for ; Mon, 19 Jun 2006 19:43:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 17:43:35 -0600 To: tcpm@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Jun 19, 2006, at 5:13 PM, David Borman wrote: > *Sigh*. This topic keeps coming up, and it's really not that > difficult. I agree, I've now seen three archived instances of this precise discussion, yet no authoritative source for implementers, and I've seen problems as a result in a live deployment. > The MSS value that is put into the TCP MSS option does *not* > include space for either TCP or IP options. You only adjust for the > fixed IP and TPC headers. When sending a packet, you calculate > Eff.snd.MSS, and in that calculation you do subtract off for the TCP > and IP options that you know are going into the packet! So this is what my opinion of what should occur is, but I'm also OK with what Joe recommended, so long as folks agree and it's documented as such. The problem is that an ambiguity exists, albeit one revisited in various forums over many years, and it should be resolved as to avoid future implementation problems. So, your recommendations about how to best avoid revisiting this topic? -danny _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 20:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTfI-0002sd-FC; Mon, 19 Jun 2006 20:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTfH-0002s8-MO for tcpm@ietf.org; Mon, 19 Jun 2006 20:00:19 -0400 Received: from gateway.insightbb.com ([74.128.0.19] helo=asav07.manage.insightbb.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTfG-0003eF-EX for tcpm@ietf.org; Mon, 19 Jun 2006 20:00:19 -0400 Received: from dhcp-74-132-237-190.insightbb.com (HELO elb.elitists.net) ([74.132.237.190]) by asav07.manage.insightbb.com with ESMTP; 19 Jun 2006 20:00:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AR4FAKLTlkSBTQ Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id BD8002BE21; Mon, 19 Jun 2006 19:59:28 -0400 (EDT) Received: by colt.internal (Postfix, from userid 3000) id 18EB0F452; Mon, 19 Jun 2006 19:59:28 -0400 (EDT) Date: Mon, 19 Jun 2006 19:59:27 -0400 From: Ethan Blanton To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Message-ID: <20060619235927.GQ31726@elb.elitists.net> Mail-Followup-To: Danny McPherson , tcpm@ietf.org References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> MIME-Version: 1.0 In-Reply-To: <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.11 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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="===============0301673135==" Errors-To: tcpm-bounces@ietf.org --===============0301673135== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JWJEtCrVvH5hpatL" Content-Disposition: inline --JWJEtCrVvH5hpatL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Danny McPherson spake unto us the following wisdom: > On Jun 19, 2006, at 5:13 PM, David Borman wrote: > > > The MSS value that is put into the TCP MSS option does *not* > >include space for either TCP or IP options. You only adjust for the > >fixed IP and TPC headers. When sending a packet, you calculate > >Eff.snd.MSS, and in that calculation you do subtract off for the TCP > >and IP options that you know are going into the packet! >=20 > So this is what my opinion of what should occur is, but I'm also > OK with what Joe recommended, so long as folks agree and it's > documented as such. In my opinion, this is the only reasonable way to define it. When a sender puts the MSS option on a SYN packet, it is indicating to the *receiver* the maximum size segment it can accept -- and it has no idea what options the *receiver* may wish to put on the TCP header. For this reason, subtracting the options the sender expects to put on its own TCP headers is useless at best -- particularly because, at SYN time, the sender doesn't even necessarily know what options it will wind up negotiating! > The problem is that an ambiguity exists, albeit one revisited in > various forums over many years, and it should be resolved as to > avoid future implementation problems. >=20 > So, your recommendations about how to best avoid revisiting > this topic? I'm not sure how the question comes up in the first place; it seems clear enough to me that there's really only One Way to Do It. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --JWJEtCrVvH5hpatL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFElzpfr9kA9Ig8HBQRAj3HAJ9qm24Vryamm4vheb77FheyBPr8BQCgxEh/ A0EJJylknRTCJ6uUuhDme7g= =po3/ -----END PGP SIGNATURE----- --JWJEtCrVvH5hpatL-- --===============0301673135== 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 --===============0301673135==-- From tcpm-bounces@ietf.org Mon Jun 19 20:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsThi-0007QH-Nv; Mon, 19 Jun 2006 20:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsThh-0007QC-BP for tcpm@ietf.org; Mon, 19 Jun 2006 20:02:49 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsThg-0004jo-06 for tcpm@ietf.org; Mon, 19 Jun 2006 20:02:49 -0400 Received: from [24.120.149.181] (unknown [10.0.12.102]) by gott.aa.arbor.net (Postfix) with ESMTP id 24A57143F6 for ; Mon, 19 Jun 2006 20:02:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44971B67.9010703@isi.edu> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <44971B67.9010703@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 18:02:40 -0600 To: tcpm@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 19, 2006, at 3:47 PM, Joe Touch wrote: > > I don't see why that's a conclusion from the above. If the sender > makes > the decision of what options to send on a per-segment basis, it > must fit > to the advertised limit on a per-segment basis. > The limit of what the receiver can buffer is the only thing here that > doesn't change after connection setup; I don't see why it should, > and it > would be hard to coordinate a change if it did. Like I said, so long as the two implementations agree we're fine. However, currently an ambiguity exists where implementations don't agree on how to calculate the advertised MSS (and subsequently, Eff.snd.MSS) and this presents an issue. With deployed implementations we also need to be concerned with backwards compatibility and therefore assuming the remote TCP will calculate options into Eff.snd.MSS in addition to the received MSS value may be a stretch. Finally, while I agree that if "advertised MSS" was used to convey absolute TCP reassembly buffer space it wouldn't be an issue, but there are implementations out there today in which this clearly is not the case. Per segment options should be considered in whatever text we generate. > ... >>>> The receiver should, of course, truncate received segments at its >>>> advertised MSS to avoid buffer overruns. >> >> Agreed, though with mismatched MTUs or the like it may lead >> to silent drops at some hop between the sender and receiver, >> no? > > They already do (PMTU failures). If the sender and receiver don't agree on semantics of this then problems can occur regardless of PMTU, as I mentioned in the first message I sent about this. >> Also, is it difficult to DoS harden such a model, or is this >> common practice today? > > I'm not sure what you mean - can you explain? WRT your comment "The receiver should, of course, truncate received segments at its advertised MSS to avoid buffer overruns" I was simply asking if by "truncate" you're suggesting that if a TCP segment exceeds available reassembly buffer space the receiving system should do what to correct/indicate the error? Is this a common practice in implementations today? > >>>> I'm not sure this needs a stand-alone I-D, or if we should >>>> collect such >>>> mods in a pending list somewhere and publish them when over some >>>> time/length threshold. >> >> I'm happy with that, I just want it definitively documented and >> referencable some place. Where would such a collection of mods >> be contained today? > > RFC 2525 is the closest thing, but it focused on implementation > issues, > not spec issues. And it's "done", which means we can't really do anything new with it.. > I'm proposing that TCPM might keep a list of such mods... I thought in the IETF Internet-Drafts for the correct means to convey such a thing - is there a better mechanism with which I'm unaware? As per David's email, I'd prefer not to revisit this again in n months and would very much like the two implementations with which I'm most concerned at the moment (per a real problem because of an ambiguity in the specs) to have some referencable point at which future specifications and implementation may comply. Thanks for your response... - -danny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFElzsmVbIg27AGOxoRAmKAAJ9KjE1ipgV/ZdsJvUbiSFXr9wZXtACgh1gp gHbbfQPtffYABb5ibIJrrvs= =4U8O -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 20:08:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTmv-0001gc-T9; Mon, 19 Jun 2006 20:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTmv-0001gR-Bi for tcpm@ietf.org; Mon, 19 Jun 2006 20:08:13 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTmu-0005GV-4N for tcpm@ietf.org; Mon, 19 Jun 2006 20:08:13 -0400 Received: from [24.120.149.181] (unknown [10.0.12.102]) by gott.aa.arbor.net (Postfix) with ESMTP id 8D834143F6 for ; Mon, 19 Jun 2006 20:08:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060619235927.GQ31726@elb.elitists.net> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <20060619235927.GQ31726@elb.elitists.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B195825-1CE9-44A7-B429-7DF7DF9A2C86@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 18:08:06 -0600 To: tcpm@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 19, 2006, at 5:59 PM, Ethan Blanton wrote: > > I'm not sure how the question comes up in the first place; it seems > clear enough to me that there's really only One Way to Do It. Heh.. With my indulgence into the issue over the past few weeks, I'm not terribly surprised that I could name three popular implementations that do it one way and two that do it another. As such, what may seem intuitive enough to one person may seem entirely different or just implementation issues to another. In addition, the fact that there are several RFCs that muddy the water further by suggestive or misleading text at best, I'm not at all surprised such an issue continues to arise. - -danny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFElzxqVbIg27AGOxoRArspAKCWDfYiQ673alad6jzvuPtBIBtKbgCfej/3 6QIIDm3LSGi6Dg+/dABXURY= =zM3c -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 19 22:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVtE-0000dk-UI; Mon, 19 Jun 2006 22:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVtD-0000df-Kn for tcpm@ietf.org; Mon, 19 Jun 2006 22:22:51 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVtC-0005WG-6O for tcpm@ietf.org; Mon, 19 Jun 2006 22:22:51 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id k5K2NBpD027303; Mon, 19 Jun 2006 21:23:11 -0500 (CDT) In-Reply-To: References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <44971B67.9010703@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7283B8A4-49E3-4B1D-9B82-1554437EA5A4@weston.borman.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] MSS & TCP Options Date: Mon, 19 Jun 2006 21:22:46 -0500 To: Danny McPherson X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Danny, On Jun 19, 2006, at 7:02 PM, Danny McPherson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Jun 19, 2006, at 3:47 PM, Joe Touch wrote: >> >> I don't see why that's a conclusion from the above. If the sender >> makes >> the decision of what options to send on a per-segment basis, it >> must fit >> to the advertised limit on a per-segment basis. > >> The limit of what the receiver can buffer is the only thing here that >> doesn't change after connection setup; I don't see why it should, >> and it >> would be hard to coordinate a change if it did. > > Like I said, so long as the two implementations agree we're fine. > However, currently an ambiguity exists where implementations don't > agree on how to calculate the advertised MSS (and subsequently, > Eff.snd.MSS) and this presents an issue. How to calculate Eff.snd.MSS is very clear in RFC 1122. On page 85, it says: Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize The "SendMSS" value is the value received in the TCP MSS option. It has been reduced by the fixed IP and TCP header sizes, i.e. 40 bytes. In the above equation, TCPhdrsize is the full size of the TCP header including any options. So the "+20" puts back the length of the fixed TCP header so that it isn't subtracted out twice. The above equation could also be: Eff.snd.MSS = min(SendMSS, MMS_S - 20) - TCPoptionsize - IPoptionsize which results in the same answer. When calculating Eff.snd.MSS, you have to account for both the TCP options and the IP options. You don't get to assume that the value received in the TCP MSS option has already been adjusted for them. > > With deployed implementations we also need to be concerned > with backwards compatibility and therefore assuming the remote > TCP will calculate options into Eff.snd.MSS in addition to the > received MSS value may be a stretch. It is not a stretch, it is a requirement of RFC 1122. Any TCP implementation that does not take into account both IP and TCP options when calculating Eff.snd.MSS is broken. RFC 1122 has been out since 1989. If the bottom line goal in interoperability, then the only way you get into trouble in this area is if a TCP implementation assumes that the received TCP MSS option has been adjusted for options and it hasn't. In this case, packets that are too large will be generated and won't get through. Conversely, if a broken TCP has adjusted down the value in the TCP MSS option that it sends to account for TCP options, and the other side also correctly adjusts down the Eff.snd.MSS to account for TCP options, then the packets that get sent will be smaller than what could really be sent, but they will still go through and interoperability will succeed. So, the only way to guarantee interoperability in the packets you send is to always assume that the TCP MSS option only reflects the fixed IP & TCP headers, and you have to take into account both IP and TCP options when calculating Eff.snd.MSS, just as required by RFC 1122. I've also re-read section 2.18 of RFC 2525, and I don't see anything in there that contradicts RFC 1122 w.r.t how Eff.snd.MSS is calculated, or how to calculate the value to put into the TCP MSS option. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 20 01:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYO6-00010d-Ka; Tue, 20 Jun 2006 01:02:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYO4-00010Y-P8 for tcpm@ietf.org; Tue, 20 Jun 2006 01:02:53 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsYO3-0001SS-Dv for tcpm@ietf.org; Tue, 20 Jun 2006 01:02:52 -0400 Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5K52olP001019 for ; Mon, 19 Jun 2006 22:02:50 -0700 (PDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5K52lVX149769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 19 Jun 2006 22:02:50 -0700 (PDT) Message-ID: <44978176.6060708@sun.com> Date: Tue, 20 Jun 2006 13:02:46 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <20060619235927.GQ31726@elb.elitists.net> In-Reply-To: <20060619235927.GQ31726@elb.elitists.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Ethan Blanton wrote: > I'm not sure how the question comes up in the first place; it seems > clear enough to me that there's really only One Way to Do It. Maybe you will find the following interesting... http://blogs.sun.com/roller/page/kcpoon/20050614 -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 20 10:18:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsh4B-0007lj-Q3; Tue, 20 Jun 2006 10:18:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsh4A-0007le-Ai for tcpm@ietf.org; Tue, 20 Jun 2006 10:18:54 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsh48-0004bu-Tq for tcpm@ietf.org; Tue, 20 Jun 2006 10:18:54 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id k5KEJDpD028861; Tue, 20 Jun 2006 09:19:14 -0500 (CDT) In-Reply-To: <44978176.6060708@sun.com> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <20060619235927.GQ31726@elb.elitists.net> <44978176.6060708@sun.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <781A7BD3-4C83-4EB7-8B10-8F8473D883BE@weston.borman.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] MSS & TCP Options Date: Tue, 20 Jun 2006 09:18:49 -0500 To: Kacheong Poon X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Interesting, yes. But I don't agree with it. The basic idea is "If I receive an MSS value of X in a SYN packet, I will not send an MSS value greater than X in my SYN,ACK". But the whole thing is premised upon a broken middle box that is manipulating down the MSS value in the SYN packet (due to its insertion of PPPoE headers) and not modifying the MSS in the returning SYN,ACK packet, and also not generating ICMP Fragmentation Needed messages. The middle box is broken. While putting in short term fixes in the hosts helps the hosts to work around the broken middle boxes, in the long run that is a disservice to the network as a whole, as it removes pressure on the vendor of the broken middle box to fix the middle box. The introduction of broken systems into the network should glaringly point out the problems of the broken systems, so that they will get noticed and fixed as soon as possible. The network as a whole shouldn't have to work around every piece of broken hardware that is added into the network. -David Borman On Jun 20, 2006, at 12:02 AM, Kacheong Poon wrote: > Ethan Blanton wrote: > >> I'm not sure how the question comes up in the first place; it seems >> clear enough to me that there's really only One Way to Do It. > > > Maybe you will find the following interesting... > > http://blogs.sun.com/roller/page/kcpoon/20050614 > > > > -- > > K. Poon. > kacheong.poon@sun.com > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 20 11:19:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi0T-0001nP-HH; Tue, 20 Jun 2006 11:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi0R-0001nJ-VZ for tcpm@ietf.org; Tue, 20 Jun 2006 11:19:07 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsi0O-0002b3-KL for tcpm@ietf.org; Tue, 20 Jun 2006 11:19:07 -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 k5KFHd225579; Tue, 20 Jun 2006 08:17:39 -0700 (PDT) Message-ID: <449811EF.7050404@isi.edu> Date: Tue, 20 Jun 2006 08:19:11 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <20060619235927.GQ31726@elb.elitists.net> <44978176.6060708@sun.com> <781A7BD3-4C83-4EB7-8B10-8F8473D883BE@weston.borman.com> In-Reply-To: <781A7BD3-4C83-4EB7-8B10-8F8473D883BE@weston.borman.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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, Kacheong Poon 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="===============1764272713==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1764272713== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2E364ADA0D2CC1BACF0ED8D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2E364ADA0D2CC1BACF0ED8D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Borman wrote: > The middle box is broken. =2E.. Or what the middle box wants do to is "broken" ;-) > The introduction of broken systems into the network should glaringly > point out the problems of the broken systems, so that they will get > noticed and fixed as soon as possible. The network as a whole shouldn'= t > have to work around every piece of broken hardware that is added into > the network. Indeed. Joe --------------enigD2E364ADA0D2CC1BACF0ED8D 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 iD8DBQFEmBHvE5f5cImnZrsRAnNfAJ4nBcGrszhZGPqDmMgzHy4QibA16QCgj3rS IEhM3UmhDgsBKcsbpPucShg= =c/EI -----END PGP SIGNATURE----- --------------enigD2E364ADA0D2CC1BACF0ED8D-- --===============1764272713== 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 --===============1764272713==-- From tcpm-bounces@ietf.org Tue Jun 20 11:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi1B-0002QH-KX; Tue, 20 Jun 2006 11:19:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi19-0002QC-SV for tcpm@ietf.org; Tue, 20 Jun 2006 11:19:51 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsi18-0002iM-HY for tcpm@ietf.org; Tue, 20 Jun 2006 11:19:51 -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 k5KFJC226154; Tue, 20 Jun 2006 08:19:12 -0700 (PDT) Message-ID: <4498124C.6060606@isi.edu> Date: Tue, 20 Jun 2006 08:20:44 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> In-Reply-To: <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> 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="===============0461213633==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0461213633== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BC2776B87BD2E8D8ABA63A8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BC2776B87BD2E8D8ABA63A8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: >=20 > On Jun 19, 2006, at 5:13 PM, David Borman wrote: >=20 >> *Sigh*. This topic keeps coming up, and it's really not that difficul= t. >=20 > I agree, I've now seen three archived instances of this precise > discussion, yet no authoritative source for implementers, and > I've seen problems as a result in a live deployment. >=20 >> The MSS value that is put into the TCP MSS option does *not* >> include space for either TCP or IP options. You only adjust for the >> fixed IP and TPC headers. When sending a packet, you calculate >> Eff.snd.MSS, and in that calculation you do subtract off for the TCP >> and IP options that you know are going into the packet! >=20 > So this is what my opinion of what should occur is, but I'm also > OK with what Joe recommended, so long as folks agree and it's > documented as such. I'm just reiterating David's summary from the E2E list. I agree with him; this issue isn't one. Like many protocol issues, it's resolved completely if you dig into the docs sufficiently - I see no reason why this issue is more obscure than any other. What you really have is a _known_ implementation error that is already described by RFC2525. What further needs to be said? Joe --------------enig3BC2776B87BD2E8D8ABA63A8 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 iD8DBQFEmBJME5f5cImnZrsRAl+wAKDqLUuYILN38gXwYju2xPZYcn8nawCgw8pA gKMo0C3clr2+YaleKoV2Cv4= =Lk41 -----END PGP SIGNATURE----- --------------enig3BC2776B87BD2E8D8ABA63A8-- --===============0461213633== 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 --===============0461213633==-- From tcpm-bounces@ietf.org Tue Jun 20 13:12:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsjm6-000572-AS; Tue, 20 Jun 2006 13:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsjm4-00056w-Ar for tcpm@ietf.org; Tue, 20 Jun 2006 13:12:24 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsjm2-00028z-Vm for tcpm@ietf.org; Tue, 20 Jun 2006 13:12:24 -0400 Received: from [24.120.149.181] (unknown [10.0.12.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id C2FFC14296 for ; Tue, 20 Jun 2006 13:12:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4498124C.6060606@isi.edu> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Tue, 20 Jun 2006 11:12:09 -0600 To: tcpm@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 20, 2006, at 9:20 AM, Joe Touch wrote: > > I'm just reiterating David's summary from the E2E list. I agree with > him; this issue isn't one. Like many protocol issues, it's resolved > completely if you dig into the docs sufficiently - I see no reason why > this issue is more obscure than any other. Really? This is surprising considering you and David disagree on what the right solution is (i.e., David says calculations should be per segment via Eff.snd.MSS and therefore advertised MSS should NOT include options, which is what I believe should occur as well; you say that advertised MSS should include options and therefore the Eff.snd.MSS should assume options were included in Eff.snd.MSS). If this is so obvious, why do you disagree with David? > What you really have is a _known_ implementation error that is already > described by RFC2525. What further needs to be said? RFC 2525 does NOT define how to calculate advertised MSS. Section 2.18's title and focus of this item in the document are even a bit misleading, considering it's actually talking about "Options missing from Effective send MSS calculation" when that's the piece that's clear in RFC 1122, it's the calculation for deriving advertised MSS that introduces this ambiguity, and "Options missing from TCP MSS calculation" is simply a symptom of that. I'd be quite content had it stated, in the "How to fix" section, that the *advertised MSS* calculation MUST NOT factor options, as they're to be calculated on a per segment basis by the sender - as this is really where the issue arises. Eff.snd.MSS is seemingly sufficiently defined in RFC 1122, but as such, it implicitly requires that a sender NOT include options in the advertised MSS. RFC 2581 introduces some new definitions to muddy the water more. RFC 2385 completely diverges from this stating "As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation." David again says "Sigh." Then provides a mailing list reference and an Appendix A pointer from RFC 1323bis (a 3 year old expired I-D). I'm confused as to why the two of you are adamant that this isn't an issue when you yourselves disagree, there's apparently no explicit definitive source about calculation of advertised MSS, we're seeing a problem from this in deployments in the field, many of the options drafts themselves are clearly contradictory and the only references you provide are an ID that expired 3 years ago and mailing list archives and suggest that's sufficient? In David's words, sigh. If there were something more clear and authoritative the issue wouldn't keep resurfacing. - - -danny - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEmCxgVbIg27AGOxoRAsLMAJ0T9/O/zJnj0cFrEJbxMNQoGCxq6ACfQiu+ ARNP+NTIzgXY1ehMndz45MA= =IpZT - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEmCxuVbIg27AGOxoRAjAgAKDOK4ec3IJC3yBOKd2mhfCI3wGlOQCgsKD0 C2pqlLNLVvYwsO+GeVKDvOQ= =1h+Q -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 20 13:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsk6w-0001JV-Dd; Tue, 20 Jun 2006 13:33:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsk6v-0001JL-9Z for tcpm@ietf.org; Tue, 20 Jun 2006 13:33:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsk6s-0003yL-Rk for tcpm@ietf.org; Tue, 20 Jun 2006 13:33:57 -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 k5KHWc201793; Tue, 20 Jun 2006 10:32:38 -0700 (PDT) Message-ID: <44983192.1080403@isi.edu> Date: Tue, 20 Jun 2006 10:34:10 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> In-Reply-To: <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> 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: b1c41982e167b872076d0018e4e1dc3c 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="===============0930896418==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0930896418== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58BD42C57A52D366DC9AE994" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58BD42C57A52D366DC9AE994 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On Jun 20, 2006, at 9:20 AM, Joe Touch wrote: >>> >>> I'm just reiterating David's summary from the E2E list. I agree with >>> him; this issue isn't one. Like many protocol issues, it's resolved >>> completely if you dig into the docs sufficiently - I see no reason wh= y >>> this issue is more obscure than any other. >=20 > Really? This is surprising considering you and David disagree on > what the right solution is (i.e., David says calculations should be > per segment via Eff.snd.MSS and therefore advertised MSS should > NOT include options, which is what I believe should occur as well; > you say that advertised MSS should include options and therefore > the Eff.snd.MSS should assume options were included in > Eff.snd.MSS). I said that: IMO, the receiver should state what it's capable of receiving; this means the limit of its space is explicit, and let the sender decide how to make each transmitted segment fit... I also said later in that same message that: - advertised MSS should include all options and headers This was intended to indicate that the advertised MSS includes the space used for all options and headers - which is why the advertiser should NOT subtract that stuff out, but the user of that info (the side sending segments based on that advertised MSS) would be doing the fitting - as the next line states: - it is the sender's responsibility to fit what it sends to that advertised limit > If this is so obvious, why do you disagree with David? I don't think we disagree at all. >>> What you really have is a _known_ implementation error that is alread= y >>> described by RFC2525. What further needs to be said? >=20 > RFC 2525 does NOT define how to calculate advertised MSS. Section > 2.18's title and focus of this item in the document are even a bit > misleading, > considering it's actually talking about "Options missing from Effective= > send > MSS calculation" when that's the piece that's clear in RFC 1122, it's t= he > calculation for deriving advertised MSS that introduces this ambiguity,= > and "Options missing from TCP MSS calculation" is simply a symptom > of that. >=20 > I'd be quite content had it stated, in the "How to fix" section, that t= he > *advertised MSS* calculation MUST NOT factor options, as they're to be > calculated on a per segment basis by the sender - as this is really whe= re > the issue arises. RFC2525 wasn't intended to imply that there were errors in specification regarding section 2.18; the error is one of implementation. > Eff.snd.MSS is seemingly sufficiently defined in RFC 1122, but as such,= > it implicitly requires that a sender NOT include options in the adverti= sed > MSS. RFC 2581 introduces some new definitions to muddy the water > more. RFC 2385 completely diverges from this stating "As with other > options that are added to every segment, the size of the MD5 option > must be factored into the MSS offered to the other side during > connection negotiation." So far, you're highlighting a possible error in 2385. That can be fixed sufficiently in any of the proposed revisions by addressing that section directly - and saying that "as with other options, this is NOT subtracted out of the advertised MSS". I.e., 2385 has the right premise (as with other options), but the wrong recommendation. 2581 defines its own terms, which has its own problems. > David again says "Sigh." Then provides a mailing list reference and > an Appendix A pointer from RFC 1323bis (a 3 year old expired I-D). >=20 > I'm confused as to why the two of you are adamant that this isn't an > issue when you yourselves disagree, there's apparently no explicit > definitive source about calculation of advertised MSS, we're seeing > a problem from this in deployments in the field, many of the options > drafts themselves are clearly contradictory and the only references > you provide are an ID that expired 3 years ago and mailing list > archives and suggest that's sufficient? >=20 > In David's words, sigh. If there were something more clear and > authoritative the issue wouldn't keep resurfacing. That's an assumption I do not agree with; we see the same issues resurfacing all over the place. More documents don't always help the situation. Joe --------------enig58BD42C57A52D366DC9AE994 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 iD8DBQFEmDGSE5f5cImnZrsRAt0GAKD2iWqqie3LXt+pxWlcCSCQzCRkXwCg/KSD Qrm4mm94qyu+PQ+Ei4CkobU= =43J/ -----END PGP SIGNATURE----- --------------enig58BD42C57A52D366DC9AE994-- --===============0930896418== 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 --===============0930896418==-- From tcpm-bounces@ietf.org Tue Jun 20 13:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskN0-0002up-OQ; Tue, 20 Jun 2006 13:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskMz-0002tz-FD for tcpm@ietf.org; Tue, 20 Jun 2006 13:50:33 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskMe-0005Jp-B6 for tcpm@ietf.org; Tue, 20 Jun 2006 13:50:13 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id k5KHoVpD029254; Tue, 20 Jun 2006 12:50:32 -0500 (CDT) In-Reply-To: <44983192.1080403@isi.edu> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> <44983192.1080403@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] MSS & TCP Options Date: Tue, 20 Jun 2006 12:50:07 -0500 To: Joe Touch X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Jun 20, 2006, at 12:34 PM, Joe Touch wrote: > > I said that: > > IMO, the receiver should state what it's capable of receiving; this > means the limit of its space is explicit, and let the sender decide > how > to make each transmitted segment fit... > > I also said later in that same message that: > > - advertised MSS should include all options and headers I think this is what is causing confusion in the current discussion. The TCP MSS option is the total amount of available data, less the fixed IP and TCP headers; i.e. the amount of TCP payload that can be received if you have no IP or TCP options (or any other headers). > > This was intended to indicate that the advertised MSS includes the > space > used for all options and headers - which is why the advertiser should > NOT subtract that stuff out, but the user of that info (the side > sending > segments based on that advertised MSS) would be doing the fitting - as > the next line states: > > - it is the sender's responsibility to fit what it sends > to that advertised limit Yes, but with the caveat that the value that was received in the TCP MSS option has already been adjusted down to reflect the size of the fixed IP and TCP headers, and that has to be taken into account when calculating Eff.snd.MSS, as described in RFC 1122. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jun 20 14:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsl5n-0007fm-Mp; Tue, 20 Jun 2006 14:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsl5m-0007fh-1F for tcpm@ietf.org; Tue, 20 Jun 2006 14:36:50 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsl5j-00036u-L3 for tcpm@ietf.org; Tue, 20 Jun 2006 14:36:50 -0400 Received: from [24.120.149.181] (unknown [10.0.12.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 9576314290 for ; Tue, 20 Jun 2006 14:36:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> <44983192.1080403@isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Tue, 20 Jun 2006 12:36:43 -0600 To: tcpm@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Jun 20, 2006, at 11:50 AM, David Borman wrote: > > On Jun 20, 2006, at 12:34 PM, Joe Touch wrote: > >> >> I said that: >> >> IMO, the receiver should state what it's capable of receiving; this >> means the limit of its space is explicit, and let the sender >> decide how >> to make each transmitted segment fit... >> >> I also said later in that same message that: >> >> - advertised MSS should include all options and headers > > I think this is what is causing confusion in the current > discussion. The > TCP MSS option is the total amount of available data, less the > fixed IP > and TCP headers; i.e. the amount of TCP payload that can be received > if you have no IP or TCP options (or any other headers). Yes, I believe this is where the confusion arises as well. >> This was intended to indicate that the advertised MSS includes the >> space >> used for all options and headers - which is why the advertiser should >> NOT subtract that stuff out, but the user of that info (the side >> sending >> segments based on that advertised MSS) would be doing the fitting >> - as >> the next line states: >> >> - it is the sender's responsibility to fit what it sends >> to that advertised limit > > Yes, but with the caveat that the value that was received in the TCP > MSS option has already been adjusted down to reflect the size of the > fixed IP and TCP headers, and that has to be taken into account when > calculating Eff.snd.MSS, as described in RFC 1122. Yes, I agree. And with the caveat that the IP and TCP Options were not calculated into the advertised MSS conveyed by the remote host, and therefore, should be considered as such when calculating Eff.snd.MSS. This is what isn't explicit in the current text. -danny _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 21 10:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3h7-0004kk-Eg; Wed, 21 Jun 2006 10:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3h6-0004kI-DT for tcpm@ietf.org; Wed, 21 Jun 2006 10:28:36 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3h4-0008LV-TB for tcpm@ietf.org; Wed, 21 Jun 2006 10:28:36 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id k5LEStpD001458; Wed, 21 Jun 2006 09:28:56 -0500 (CDT) In-Reply-To: References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> <44983192.1080403@isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AC39084-9FDC-429D-8883-8EE04A34CA08@weston.borman.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] MSS & TCP Options Date: Wed, 21 Jun 2006 09:28:29 -0500 To: Danny McPherson X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Jun 20, 2006, at 1:36 PM, Danny McPherson wrote: ... > Yes, I agree. And with the caveat that the IP and TCP Options > were not calculated into the advertised MSS conveyed by the remote > host, and therefore, should be considered as such when calculating > Eff.snd.MSS. This is what isn't explicit in the current text. > > -danny Huh? Section 4.2.2.6 of RFC 1122 is very explicit about how to calculate Eff.snd.MSS, there is no ambiguity there. You adjust down to account for any IP and TCP options. The value to put into the TCP MSS option is: MMS_R - 20 (section 4.2.2.6) MMS_R = EMTU_R - 20 (section 3.3.2) So, that's EMTU_R - 40; 20 bytes for the fixed TCP header, 20 bytes for the fixed IP header. And that isn't explicit enough? -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 21 11:25:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Zk-0001T6-Kx; Wed, 21 Jun 2006 11:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Zj-0001T1-FS for tcpm@ietf.org; Wed, 21 Jun 2006 11:25:03 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Zg-0008LT-3l for tcpm@ietf.org; Wed, 21 Jun 2006 11:25:03 -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 k5LFOb221141; Wed, 21 Jun 2006 08:24:37 -0700 (PDT) Message-ID: <44996511.2070704@isi.edu> Date: Wed, 21 Jun 2006 08:26:09 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> <44983192.1080403@isi.edu> <6AC39084-9FDC-429D-8883-8EE04A34CA08@weston.borman.com> In-Reply-To: <6AC39084-9FDC-429D-8883-8EE04A34CA08@weston.borman.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: 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="===============0539821108==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0539821108== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig608CF2F18F53E48ABD25982B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig608CF2F18F53E48ABD25982B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Borman wrote: >=20 > On Jun 20, 2006, at 1:36 PM, Danny McPherson wrote: > ... >> Yes, I agree. And with the caveat that the IP and TCP Options >> were not calculated into the advertised MSS conveyed by the remote >> host, and therefore, should be considered as such when calculating >> Eff.snd.MSS. This is what isn't explicit in the current text. >> >> -danny >=20 > Huh? Section 4.2.2.6 of RFC 1122 is very explicit about how to > calculate Eff.snd.MSS, there is no ambiguity there. You adjust down to= > account for any IP and TCP options. >=20 > The value to put into the TCP MSS option is: > MMS_R - 20 (section 4.2.2.6) > MMS_R =3D EMTU_R - 20 (section 3.3.2) > So, that's EMTU_R - 40; 20 bytes for the fixed TCP header, 20 bytes for= > the fixed IP header. >=20 > And that isn't explicit enough? Right - it doesn't matter whether the other side erroneously reduces advertised MSS by the size of options it expects; if this side implements 1122 as required, the transfer might be a little less efficient but it won't break. Joe --------------enig608CF2F18F53E48ABD25982B 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 iD8DBQFEmWURE5f5cImnZrsRAkexAKCbjU9v+mJ+iWwxCeYWuG2zVEo4AACcDbkL RfOoTV09Avk70CM5TBlAknQ= =mVBI -----END PGP SIGNATURE----- --------------enig608CF2F18F53E48ABD25982B-- --===============0539821108== 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 --===============0539821108==-- From tcpm-bounces@ietf.org Wed Jun 21 12:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5ul-0000Sw-1g; Wed, 21 Jun 2006 12:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5uj-0000SY-Li for tcpm@ietf.org; Wed, 21 Jun 2006 12:50:49 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5mG-0007zy-HU for tcpm@ietf.org; Wed, 21 Jun 2006 12:42:05 -0400 Received: from [24.120.149.181] (unknown [10.0.12.167]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 69397144AC for ; Wed, 21 Jun 2006 12:41:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <6AC39084-9FDC-429D-8883-8EE04A34CA08@weston.borman.com> References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> <44983192.1080403@isi.edu> <6AC39084-9FDC-429D-8883-8EE04A34CA08@weston.borman.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88A095B6-7982-48DB-A967-5C877D7E18DE@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options Date: Wed, 21 Jun 2006 10:41:51 -0600 To: tcpm@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Jun 21, 2006, at 8:28 AM, David Borman wrote: > > Huh? Section 4.2.2.6 of RFC 1122 is very explicit about how to > calculate > Eff.snd.MSS, there is no ambiguity there. You adjust down to > account for > any IP and TCP options. > > The value to put into the TCP MSS option is: > MMS_R - 20 (section 4.2.2.6) > MMS_R = EMTU_R - 20 (section 3.3.2) > So, that's EMTU_R - 40; 20 bytes for the fixed TCP header, 20 bytes > for > the fixed IP header. I feel like we're going in circles here, perhaps my wording was a bit loose. What I meant was that the confusion surrounding this whole issue is simply because: o there are implementations that calculate options into the advertised MSS (because of inconsistencies that documents like RFC 2385 introduce) o and implicitly, as a result, implementations that expect the remote host to include options in the MSS it advertised o and therefore, said implementation does not comply with RFC 1122s Eff.snd.MSS algorithm by factoring options on a per-segment basis when sending o and if the two TCPs don't agree on this (which is what we're experiencing) then there's some probability you run into brokenness. If the two TCPs agree on Eff.snd.MSS calculation but not the advertised MSS calculation then you likely just get an inefficiency where segments could be a bit larger - but this is still an issue. However, what we've seen is that implementations which presume options were included in the MSS advertised from the remote system tend to not (re)calculate options on a per segment basis when sending, which is perhaps something that seems intuitive to an implementer. My position is that because Eff.snd.MSS says you calculate options when sending on a per segment basis then options MUST NOT be conveyed in the advertised MSS - but such an implicit requirement in RFC 1122 for advertised MSS calculations and inconsistencies introduced by RFC 2385 and the like, the issue keeps resurfacing. The fact that even you and Joe seem to disagree on this is indicative of a problem, the fact that it keeps resurfacing indicates there's at least some ambiguity, and the fact that I'm seeing three widely deployed implementations that do it one way and two that do it another, well, is an existence proof. -danny _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jun 21 13:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6BO-0004g4-L4; Wed, 21 Jun 2006 13:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6BN-0004fz-8v for tcpm@ietf.org; Wed, 21 Jun 2006 13:08:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6BL-0002oH-TI for tcpm@ietf.org; Wed, 21 Jun 2006 13:08:01 -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 k5LH71216722; Wed, 21 Jun 2006 10:07:01 -0700 (PDT) Message-ID: <44997D11.3000705@isi.edu> Date: Wed, 21 Jun 2006 10:08:33 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Danny McPherson Subject: Re: [tcpm] MSS & TCP Options References: <8E7934BE-2C32-4D5B-859B-A2CA334C0762@tcb.net> <20060619131628.611e5ffd@localhost> <92C184F7-8E97-471B-9130-F67926B65184@tcb.net> <44970EF8.3060007@isi.edu> <36A745D2-C796-4537-A9EC-C7C52BA3537A@weston.borman.com> <87AFFF0D-B206-4AB0-91E6-D118A42B60FE@tcb.net> <4498124C.6060606@isi.edu> <93C9E6EE-3A2A-4853-AF1B-C8D8FB912B14@tcb.net> <44983192.1080403@isi.edu> <6AC39084-9FDC-429D-8883-8EE04A34CA08@weston.borman.com> <88A095B6-7982-48DB-A967-5C877D7E18DE@tcb.net> In-Reply-To: <88A095B6-7982-48DB-A967-5C877D7E18DE@tcb.net> 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: f60d0f7806b0c40781eee6b9cd0b2135 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="===============1253912913==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1253912913== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD03FCE7B92635F10444421E1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD03FCE7B92635F10444421E1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny McPherson wrote: >=20 > On Jun 21, 2006, at 8:28 AM, David Borman wrote: >> >> Huh? Section 4.2.2.6 of RFC 1122 is very explicit about how to calcul= ate >> Eff.snd.MSS, there is no ambiguity there. You adjust down to account = for >> any IP and TCP options. >> >> The value to put into the TCP MSS option is: >> MMS_R - 20 (section 4.2.2.6) >> MMS_R =3D EMTU_R - 20 (section 3.3.2) >> So, that's EMTU_R - 40; 20 bytes for the fixed TCP header, 20 bytes fo= r >> the fixed IP header. >=20 > I feel like we're going in circles here, perhaps my wording was a > bit loose. What I meant was that the confusion surrounding this > whole issue is simply because: >=20 > o there are implementations that calculate options into > the advertised MSS (because of inconsistencies that > documents like RFC 2385 introduce) This was addressed in RFC2525 - which came 8 months later. 2385 is already somewhat in flux; we can address than in one of the updates (i.e., correct the erroneous text). The rest seems to be based solely on 2385. Let's just fix that (which we have three proposals for anyway)... > o and implicitly, as a result, implementations that expect the > remote host to include options in the MSS it advertised >=20 > o and therefore, said implementation does not comply with > RFC 1122s Eff.snd.MSS algorithm by factoring options on > a per-segment basis when sending >=20 > o and if the two TCPs don't agree on this (which is what we're > experiencing) then there's some probability you run into > brokenness. Joe --------------enigD03FCE7B92635F10444421E1 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 iD8DBQFEmX0RE5f5cImnZrsRArQ9AJ9RZ6NlIojeNkeWKaDeOgDBwp45ZACgl/l9 QyfMEysVtaXAgCmg+sWv83c= =kdS5 -----END PGP SIGNATURE----- --------------enigD03FCE7B92635F10444421E1-- --===============1253912913== 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 --===============1253912913==-- From tcpm-bounces@ietf.org Wed Jun 21 21:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDiq-0006rD-DA; Wed, 21 Jun 2006 21:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDio-0006r8-SP for tcpm@ietf.org; Wed, 21 Jun 2006 21:11:02 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtDin-0005V9-Hk for tcpm@ietf.org; Wed, 21 Jun 2006 21:11:02 -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 k5M1B0Il075792; Wed, 21 Jun 2006 18:11:00 -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 6902E77B50B; Wed, 21 Jun 2006 21:10:56 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3B52A42837A; Wed, 21 Jun 2006 21:09:52 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Nobody Told Me MIME-Version: 1.0 Date: Wed, 21 Jun 2006 21:09:51 -0400 Message-Id: <20060622010952.3B52A42837A@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Ted Faber Subject: [tcpm] tcpsecure status 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="===============1791843646==" Errors-To: tcpm-bounces@ietf.org --===============1791843646== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- The "tcpsecure" document has been revised. You can find its current version (draft-ietf-tcpm-tcpsecure-05.txt) in the archives. Our hope is that this document is nearly ready for WGLC (although we have not yet read the latest ourselves). There will be agenda time for this in Montreal and we encourage folks to read this version and come ready to participate or send comments to the list. Mark & Ted --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEme3fWyrrWs4yIs4RArNUAKCCkXoAqKzSFgMpHQAO/z217cfa6QCglKTB mkcJkFbBnS4gxf4puc2npxU= =nnVW -----END PGP SIGNATURE----- --=_bOundary-- --===============1791843646== 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 --===============1791843646==-- From tcpm-bounces@ietf.org Wed Jun 21 21:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDje-0007Ow-Ri; Wed, 21 Jun 2006 21:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDjc-0007Or-Nx for tcpm@ietf.org; Wed, 21 Jun 2006 21:11:53 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtDjb-0005Wo-DU for tcpm@ietf.org; Wed, 21 Jun 2006 21:11: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 k5M1Bogn075814; Wed, 21 Jun 2006 18:11: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 8C25A77A71D; Wed, 21 Jun 2006 21:11:48 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7780942838A; Wed, 21 Jun 2006 21:10:44 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Nobody Told Me MIME-Version: 1.0 Date: Wed, 21 Jun 2006 21:10:44 -0400 Message-Id: <20060622011044.7780942838A@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Ted Faber Subject: [tcpm] syn flooding document 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="===============0845583524==" Errors-To: tcpm-bounces@ietf.org --===============0845583524== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Based on the list discussion sometime back, we think there is plenty of energy in the WG to take on the SYN flooding document (draft-eddy-syn-flood-02.txt) as a WG item. Please yell if you think we have erred in assessing consensus. We intend to allocate agenda time for the document in Montreal and therefore you're encouraged to read through the document and come prepared. List comments are also quite welcome, of course. Mark & Ted --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEme4UWyrrWs4yIs4RAnqbAJ9d47ROMO8y7p7Rrh70jyzRLhWS4QCghSQ7 fcCYJC17V57kzVOjBZh//JI= =xSWl -----END PGP SIGNATURE----- --=_bOundary-- --===============0845583524== 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 --===============0845583524==-- From tcpm-bounces@ietf.org Thu Jun 22 07:08:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN2d-000269-U1; Thu, 22 Jun 2006 07:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN2c-000264-8K for tcpm@ietf.org; Thu, 22 Jun 2006 07:08:06 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtN2a-0004AE-W2 for tcpm@ietf.org; Thu, 22 Jun 2006 07:08:06 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.27]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 07:08:04 -0400 Received: from himalaya.cs.cornell.edu ([128.84.223.110]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 07:08:04 -0400 From: Saikat Guha To: tcpm@ietf.org In-Reply-To: References: Date: Thu, 22 Jun 2006 12:08:03 +0100 Message-Id: <1150974483.5163.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 22 Jun 2006 11:08:04.0033 (UTC) FILETIME=[21E84B10:01C695EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [tcpm] Re: I-D ACTION:draft-ietf-behave-tcp-01.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: , Content-Type: multipart/mixed; boundary="===============0118666893==" Errors-To: tcpm-bounces@ietf.org --===============0118666893== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zzuZ1FZewfo3Imjhy2EV" --=-zzuZ1FZewfo3Imjhy2EV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks, An updated version of the BEHAVE-TCP draft is now available. The major changes from -00 are listed below.=20 The primary open issue is that of handling unsolicited inbound SYN packets -- i.e. to report an error, or silently drop, or something in between. (Note: these SYN packets are different from SYN packets that are part of a TCP Simultaneous-Open attempt, which are in fact solicited.) The draft addresses the concerns in Section 4.3, REQ-4 and presents several alternatives. We expect to resolve this issue at the BEHAVE WG meeting at IETF. If you have any opinions on the matter please attend the session or email the list in advance. We will summarize the decision taken in the TCPM meeting for those that cannot attend BEHAVE.=20 On Tue, 2006-06-20 at 15:50 -0400, Internet-Drafts@ietf.org wrote: > Title : NAT Behavioral Requirements for TCP > Author(s) : S. Guha, et al. > Filename : draft-ietf-behave-tcp-01.txt > Pages : 19 > Date : 2006-6-20 > =09 > This document defines a set of requirements for NATs that handle TCP > that would allow many applications, such as peer-to-peer applications > and on-line games, to work consistently. Developing NATs that meet > this set of requirements will greatly increase the likelihood that > these applications will function properly. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-01.txt Discussion points on- and off- list since -00 have been merged.=20 Big changes from -00 are: 1. Document is self standing. Understanding BEHAVE-UDP is no longer a prerequisite for this document. 2. Handling of unsolicited inbound SYN (REQ-4) is an open issue. The alternative wordings are mentioned in the document. (This email is being sent to BEHAVE and TCPM) cheers, --=20 Saikat --=-zzuZ1FZewfo3Imjhy2EV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEmnoTnFltqi691/oRAiiQAJ99QtJPKXoU54z/5aPEpnOIzyWaHACeLPE3 cK9185K8iyyIbtzqoxRO2qI= =LY2/ -----END PGP SIGNATURE----- --=-zzuZ1FZewfo3Imjhy2EV-- --===============0118666893== 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 --===============0118666893==-- From tcpm-bounces@ietf.org Thu Jun 22 10:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQ0b-0003mE-Tg; Thu, 22 Jun 2006 10:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQ0a-0003ls-MZ for tcpm@ietf.org; Thu, 22 Jun 2006 10:18:12 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQ0Z-0007os-8n for tcpm@ietf.org; Thu, 22 Jun 2006 10:18:12 -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 k5MEHwHb008109; Thu, 22 Jun 2006 07:17:58 -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 D779A77A9D4; Thu, 22 Jun 2006 10:17:56 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3A22C428B82; Thu, 22 Jun 2006 10:16:51 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Nobody Told Me MIME-Version: 1.0 Date: Thu, 22 Jun 2006 10:16:51 -0400 Message-Id: <20060622141651.3A22C428B82@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Ethan Blanton , Vern Paxson Subject: [tcpm] new version of 2581bis 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="===============0207043363==" Errors-To: tcpm-bounces@ietf.org --===============0207043363== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline [I gave my chair hat to Ted, so I can't be wearing it. Maybe he won't give it back.] Folks- We just sent off a new version of the 2581 revision. Being a busy time I am not sure when it will appear in the archives, but you can slurp it from: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-01.txt We believe with one exception (see below) that we have incorporated all the feedback from the list and from the Dallas meeting. If folks could have a look through the document and send comments (on or off list) we'd appreciate it. The one thing that we have not yet done is to change the setting of the ssthresh after multiple RTOs. The text from -00 has been left. After some discussions amongst the authors we are inclined to change the text, but want to get consensus from the WG on the approach first. The point in noting this here is so that folks don't think we have ignored the issue. When I get a few minutes, I will frame out our thinking on this issue on the list and see what you folks think. I believe we'll also have some time in Montreal to discuss the issue (and, any others that folks want to raise, of course). allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEmqZSWyrrWs4yIs4RAtovAJ0YgdaHEx3U6f+q13KBmdUA1N71PACfQKzR PqYD2+wx+fIq6Z35W2ijODk= =gWaW -----END PGP SIGNATURE----- --=_bOundary-- --===============0207043363== 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 --===============0207043363==-- From tcpm-bounces@ietf.org Thu Jun 22 20:20:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZP3-0006aI-GS; Thu, 22 Jun 2006 20:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZOz-0006YP-VV; Thu, 22 Jun 2006 20:20:01 -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 1FtYUx-00008i-GO; Thu, 22 Jun 2006 19:22:07 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtY3E-0006xd-P2; Thu, 22 Jun 2006 18:53:30 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2mU022653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007tp-AJ; Thu, 22 Jun 2006 18:50:02 -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: Thu, 22 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc2581bis-01.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 Congestion Control Author(s) : M. Allman, et al. Filename : draft-ietf-tcpm-rfc2581bis-01.txt Pages : 15 Date : 2006-6-22 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-01.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-rfc2581bis-01.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-rfc2581bis-01.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-6-22161320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc2581bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22161320.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 Sun Jun 25 22:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fugzu-0008E0-Ly; Sun, 25 Jun 2006 22:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fugzt-00088o-9q; Sun, 25 Jun 2006 22:38:45 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fugzq-0005KH-U5; Sun, 25 Jun 2006 22:38:45 -0400 Received: from [128.9.176.34] (c1-vpn4.isi.edu [128.9.176.34]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5Q2bl226727; Sun, 25 Jun 2006 19:37:47 -0700 (PDT) Message-ID: <449F4874.5050701@isi.edu> Date: Sun, 25 Jun 2006 19:37:40 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: tcpm@ietf.org References: <4489EFB6.3020309@isi.edu> In-Reply-To: <4489EFB6.3020309@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: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tsvwg@ietf.org Subject: [tcpm] updated I-D: TCP Simple Authentication Option 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="===============1872482585==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1872482585== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6C2A0FF4BB72DBE71ED54913" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C2A0FF4BB72DBE71ED54913 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, The above I-D has just been updated. It is intended to provide a simpler alternative to updating TCP/MD5. Comments welcome. The update allows rekeying during a connection, and as a result removes all discussion of BGP graceful restart. It still assumes that all key management is external to TCP; this is similar to how the IKE is external to AH/ESP in the IPsec suite. It is currently available at: http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-01.txt (and should appear in the usual places very shortly) Joe and Allison --------------enig6C2A0FF4BB72DBE71ED54913 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 iD8DBQFEn0h0E5f5cImnZrsRAi7dAJ9pGTvDftmt34mqoTex+BgoHlsbUwCfS4gy 2CfDNIwlDevXULeOG6iS7G4= =GIY+ -----END PGP SIGNATURE----- --------------enig6C2A0FF4BB72DBE71ED54913-- --===============1872482585== 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 --===============1872482585==-- From tcpm-bounces@ietf.org Wed Jun 28 19:41:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvjet-0005Bj-Vg; Wed, 28 Jun 2006 19:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvjet-0005Be-8W for tcpm@ietf.org; Wed, 28 Jun 2006 19:41:23 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvjer-00085B-Ts for tcpm@ietf.org; Wed, 28 Jun 2006 19:41:23 -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 k5SNfI0K016694 for ; Wed, 28 Jun 2006 16:41:18 -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 ACD0D77AF5C for ; Wed, 28 Jun 2006 19:41:16 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 260DF42E689 for ; Wed, 28 Jun 2006 19:40:10 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lodi MIME-Version: 1.0 Date: Wed, 28 Jun 2006 19:40:09 -0400 Message-Id: <20060628234010.260DF42E689@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [tcpm] preliminary agenda for ietf66 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="===============0097835997==" Errors-To: tcpm-bounces@ietf.org --===============0097835997== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Below is the *preliminary* TCPM agenda for the TCPM meeting in Montreal. allman TCPM Agenda IETF 66, Montreal Thu, Jul/13/2006, 1300-1500 + Status, chairs, 5-10min + WG items: (40-50min) Blind Attack Robustness draft-ietf-tcpm-tcpsecure-05.txt Randall Stewart, 10min SYN Flooding draft-eddy-syn-flood-02.txt Wesley Eddy, 10min Revising RFC 2581 draft-ietf-tcpm-rfc2581bis-01.txt Mark Allman, 10-15min Anti-Spoof draft-ietf-tcpm-tcp-antispoof-04.txt Joe Touch, 10-15min + Cross-WG items: (20min) BEHAVE: NAT requirements for TCP draft-ietf-behave-tcp-01.txt Saikat Guha, 10min RDDP: Framing in TCP draft-ietf-rddp-mpa-04.txt David Black, 10min + Non-WG drafts: (40min) TCP & Connectivity Change draft-schuetz-tcpm-tcp-rlci-00.txt Wesley Eddy, 10min --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEoxNZWyrrWs4yIs4RAnlTAJ9pbrKEX/XgDaFWSv5D0J/Tmzm7BQCgnprj 9Ke/eTdoY7TvZmpf2KfER9g= =Fv29 -----END PGP SIGNATURE----- --=_bOundary-- --===============0097835997== 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 --===============0097835997==-- From tcpm-bounces@ietf.org Fri Jun 30 12:54:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMGH-00086h-Dr; Fri, 30 Jun 2006 12:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMGF-00086N-VZ for tcpm@ietf.org; Fri, 30 Jun 2006 12:54:31 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwMGE-0005EP-IZ for tcpm@ietf.org; Fri, 30 Jun 2006 12:54:31 -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 k5UGrSp06491 for ; Fri, 30 Jun 2006 09:53:28 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k5UGrSmS055212 for tcpm@ietf.org; Fri, 30 Jun 2006 09:53:28 -0700 (PDT) (envelope-from faber) Date: Fri, 30 Jun 2006 09:53:28 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20060630165328.GI53759@hut.isi.edu> Mime-Version: 1.0 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: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [tcpm] Current agenda 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="===============0005411739==" Errors-To: tcpm-bounces@ietf.org --===============0005411739== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QxN5xOWGsmh5a4wb" Content-Disposition: inline --QxN5xOWGsmh5a4wb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The current TCPM agenda for Montreal is posted at=20 http://www3.ietf.org/proceedings/06jul/agenda/tcpm.txt It's very full. Still, if you have requests for changes, please post to the list or tcpm-chairs@tools.ietf.org . While there may be some more changes coming before Montreal, we think this is likely to be the plan. --=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 --QxN5xOWGsmh5a4wb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEpVcIaUz3f+Zf+XsRAtueAKDsJRnUZWCM7Ya/cjV31T95DypDWQCgnhJU c561OgsRldDlRCeBgzr2IlE= =QPC4 -----END PGP SIGNATURE----- --QxN5xOWGsmh5a4wb-- --===============0005411739== 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 --===============0005411739==--