Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sun, Aug 23, 2015 at 7:28 PM, David Mazieres wrote: > Watson Ladd writes: > >> Suppose everyone behaves the way you suggest. How unhappy are they >> with using X or Y? Clearly not very much: they were willing to use it >> if the other side didn't want their preference. > > Actually, people have *very* strong opinions about crypto and are > willing to lobby pretty hard for particular algorithms and protocols. > We should ensure such lobbying is directed towards OS vendors *after* > TCP-ENO is standardized, not towards the working group beforehand (where > it will further slow us down undermine TCP-ENO's goal of breaking the > working group deadlock). Who are people? Certainly not the people willing to use the alternative algorithm if they have to. The problem is with the existence of sites where only one algorithm must be used, and the OS is configured accordingly. > >> The result of wanting to support every possible combination of >> preferences and admin interface is having dead options linger forever >> as the sysadmins keep copypasta in config files alive forever. I'd >> rather order my crypto from McSorley's. > > The fact that we have way too many encryption options floating around > does not mean all ciphersuites can be strictly ordered by security, for > the simple reason that nobody can predict the future. Cryptanalysis may > alter the relative security of different algorithms at any time. Or > some NIST scandal might erupt casting doubt on the design methodology of > P-512 compared to the nominally weaker Curve25519. At such points, OS > vendors need the ability to re-prioritize cipher suites without breaking > backwards compatibility. Am I proposing a fixed, static ordering? No. I'm proposing that in response to cryptanalysis we have a functional migration plan, and the negotiation mechanism to support it. We start with version 1, when that becomes untenable move to version 2. This has eliminated SSHv1 from the Internet. The alternative plan has never eliminated any cipher completely. > > David -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Watson Ladd writes: > Suppose everyone behaves the way you suggest. How unhappy are they > with using X or Y? Clearly not very much: they were willing to use it > if the other side didn't want their preference. Actually, people have *very* strong opinions about crypto and are willing to lobby pretty hard for particular algorithms and protocols. We should ensure such lobbying is directed towards OS vendors *after* TCP-ENO is standardized, not towards the working group beforehand (where it will further slow us down undermine TCP-ENO's goal of breaking the working group deadlock). > The result of wanting to support every possible combination of > preferences and admin interface is having dead options linger forever > as the sysadmins keep copypasta in config files alive forever. I'd > rather order my crypto from McSorley's. The fact that we have way too many encryption options floating around does not mean all ciphersuites can be strictly ordered by security, for the simple reason that nobody can predict the future. Cryptanalysis may alter the relative security of different algorithms at any time. Or some NIST scandal might erupt casting doubt on the design methodology of P-512 compared to the nominally weaker Curve25519. At such points, OS vendors need the ability to re-prioritize cipher suites without breaking backwards compatibility. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sun, Aug 23, 2015 at 2:33 PM, David Mazieres wrote: > Watson Ladd writes: > >>> Such a linear ordering would be very hard to achieve, given that >>> different parts of the world trust/mistrust different crypto algorithms. >>> Even among cipher suites discussed so far, how would we order >>> P-256/AES-128 vs. Curve25519/Chacha/Poly1305. The former set is better >>> is the sense that it is more established. The latter is better in the >>> sense that it is newer, potentially more efficient, and (for the >>> paranoid) less tainted by government involvement. I think realistically >>> the preference has to be left to the individual host configuration >>> rather than the IETF. >> >> Let's consider what this actually means. Hosts that implement 1 of two >> options because they don't trust the other one to provide adequate >> security will not talk to the ones that make the wrong choice. Hosts >> that implement both would be fine picking just one, in fact prefer it >> as it reduces the amount of work they have to do. >> >> But by having ranking preferences, we're in fact saying "you would be >> fine with picking one for improved interop, but we're going to force >> you to make a choice that complicates your implementation, because we >> assume you are an expert in cryptanalysis research and we are not". >> Picking one suite that's widely acceptable is far better than >> providing a smorgasbord. > > Well, hypothetically, say the US prefers spec X and the EU prefers spec > Y. The goal is that two hosts in the US would always choose spec X and > two hosts in the EU would always chose spec Y. But when a host in the > US communicates with a host in the EU, we don't really care as > much--they could choose X or Y, so we might as well base it on the > preferences of the passive opener. However, hard-coding the spec > rankings risks delaying standardization to argue over which specs should > take priority. Suppose everyone behaves the way you suggest. How unhappy are they with using X or Y? Clearly not very much: they were willing to use it if the other side didn't want their preference. The result of wanting to support every possible combination of preferences and admin interface is having dead options linger forever as the sysadmins keep copypasta in config files alive forever. I'd rather order my crypto from McSorley's. > David -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Watson Ladd writes: >> Such a linear ordering would be very hard to achieve, given that >> different parts of the world trust/mistrust different crypto algorithms. >> Even among cipher suites discussed so far, how would we order >> P-256/AES-128 vs. Curve25519/Chacha/Poly1305. The former set is better >> is the sense that it is more established. The latter is better in the >> sense that it is newer, potentially more efficient, and (for the >> paranoid) less tainted by government involvement. I think realistically >> the preference has to be left to the individual host configuration >> rather than the IETF. > > Let's consider what this actually means. Hosts that implement 1 of two > options because they don't trust the other one to provide adequate > security will not talk to the ones that make the wrong choice. Hosts > that implement both would be fine picking just one, in fact prefer it > as it reduces the amount of work they have to do. > > But by having ranking preferences, we're in fact saying "you would be > fine with picking one for improved interop, but we're going to force > you to make a choice that complicates your implementation, because we > assume you are an expert in cryptanalysis research and we are not". > Picking one suite that's widely acceptable is far better than > providing a smorgasbord. Well, hypothetically, say the US prefers spec X and the EU prefers spec Y. The goal is that two hosts in the US would always choose spec X and two hosts in the EU would always chose spec Y. But when a host in the US communicates with a host in the EU, we don't really care as much--they could choose X or Y, so we might as well base it on the preferences of the passive opener. However, hard-coding the spec rankings risks delaying standardization to argue over which specs should take priority. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sun, Aug 23, 2015 at 12:42 PM, David Mazieres wrote: > Watson Ladd writes: > >> Think of this "fixed ordering" as versioning, like HTTP/0.9, 1.0, 1.1, >> 2.0, etc. The idea is that we'd only introduce new versions when we >> knew they were stronger than the old ones. > > Such a linear ordering would be very hard to achieve, given that > different parts of the world trust/mistrust different crypto algorithms. > Even among cipher suites discussed so far, how would we order > P-256/AES-128 vs. Curve25519/Chacha/Poly1305. The former set is better > is the sense that it is more established. The latter is better in the > sense that it is newer, potentially more efficient, and (for the > paranoid) less tainted by government involvement. I think realistically > the preference has to be left to the individual host configuration > rather than the IETF. Let's consider what this actually means. Hosts that implement 1 of two options because they don't trust the other one to provide adequate security will not talk to the ones that make the wrong choice. Hosts that implement both would be fine picking just one, in fact prefer it as it reduces the amount of work they have to do. But by having ranking preferences, we're in fact saying "you would be fine with picking one for improved interop, but we're going to force you to make a choice that complicates your implementation, because we assume you are an expert in cryptanalysis research and we are not". Picking one suite that's widely acceptable is far better than providing a smorgasbord. > > David -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Watson Ladd writes: > Think of this "fixed ordering" as versioning, like HTTP/0.9, 1.0, 1.1, > 2.0, etc. The idea is that we'd only introduce new versions when we > knew they were stronger than the old ones. Such a linear ordering would be very hard to achieve, given that different parts of the world trust/mistrust different crypto algorithms. Even among cipher suites discussed so far, how would we order P-256/AES-128 vs. Curve25519/Chacha/Poly1305. The former set is better is the sense that it is more established. The latter is better in the sense that it is newer, potentially more efficient, and (for the paranoid) less tainted by government involvement. I think realistically the preference has to be left to the individual host configuration rather than the IETF. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sun, Aug 23, 2015 at 9:38 AM, David Mazieres wrote: > Watson Ladd writes: > >> So 50% of the time, encryption fails between two parties both >> supporting the spec, when using simultaneous open. Why not impose a >> fixed ordering on all possible options and use the best mutually >> supported option, aka versioning? > > No, encryption fails 100% of the time, because the b bit defaults to 0. > As currently written, TCP-ENO requires application involvement to enable > encryption under simultaneous open. Ok, I got confused about what b was doing. I thought it was disambiguating and picked randomly. > > The fixed ordering seems potentially harmful, because it might > prioritize weak protocols over newer strong ones. But maybe we could > have some kind of combination, like assign all suboptions consecutive > numbers in each SYN, and take set of suboptions which have the maximum > value of the sum of the two numbers in the two SYN segments, and then > apply the fixed ordering based on that? (Maximum will favor > variable-length options.) We're definitely open to suggestions, but I > worry this can get kind of complicated pretty quickly. Think of this "fixed ordering" as versioning, like HTTP/0.9, 1.0, 1.1, 2.0, etc. The idea is that we'd only introduce new versions when we knew they were stronger than the old ones. > >> My question is as follows: If we're willing to add half an RTT of >> latency because we can't put key material in the first flight, >> we can do the following exchange in the following manner >> A->B "I can speak X,Y,Z" >> B->A: "X, and here is my key share" >> A->B: "here is my key share". > > That's certainly the kind of thing TCP-ENO is designed to allow. > However, we don't completely rule out doing the key exchange in the SYN, > as that may turn out to be a useful encryption spec down the line. > >> In the simultaneous case we can do: (using ; as sequencing mark) >> A->B: "I speak X, Y, Z" >> B->A: "I speak X,Y,Z"; >> A->B: "My key" >> B->A "My key" >> >> A and B both know that X, Y, Z are ordered, and so can agree. >> Now, both kinds of message are completely different, and so shouldn't >> be variations on the same kind to avoid attacks based on confusing SYN >> with SYN-ACK. > > Something like this might be viable. Please spec it out in a bit more > detail. Will do sometime. > > David -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Watson Ladd writes: > So 50% of the time, encryption fails between two parties both > supporting the spec, when using simultaneous open. Why not impose a > fixed ordering on all possible options and use the best mutually > supported option, aka versioning? No, encryption fails 100% of the time, because the b bit defaults to 0. As currently written, TCP-ENO requires application involvement to enable encryption under simultaneous open. The fixed ordering seems potentially harmful, because it might prioritize weak protocols over newer strong ones. But maybe we could have some kind of combination, like assign all suboptions consecutive numbers in each SYN, and take set of suboptions which have the maximum value of the sum of the two numbers in the two SYN segments, and then apply the fixed ordering based on that? (Maximum will favor variable-length options.) We're definitely open to suggestions, but I worry this can get kind of complicated pretty quickly. > My question is as follows: If we're willing to add half an RTT of > latency because we can't put key material in the first flight, > we can do the following exchange in the following manner > A->B "I can speak X,Y,Z" > B->A: "X, and here is my key share" > A->B: "here is my key share". That's certainly the kind of thing TCP-ENO is designed to allow. However, we don't completely rule out doing the key exchange in the SYN, as that may turn out to be a useful encryption spec down the line. > In the simultaneous case we can do: (using ; as sequencing mark) > A->B: "I speak X, Y, Z" > B->A: "I speak X,Y,Z"; > A->B: "My key" > B->A "My key" > > A and B both know that X, Y, Z are ordered, and so can agree. > Now, both kinds of message are completely different, and so shouldn't > be variations on the same kind to avoid attacks based on confusing SYN > with SYN-ACK. Something like this might be viable. Please spec it out in a bit more detail. David ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Eric Rescorla writes: > But, as I note, at the cost of a byte if you *ever* want to have >1. My > experience > is that things get more complicated, rather than less. Well, I'd say TCP's experience is that option space gets more precious, not less. I think the most common case is going to be that the SYN proposes a bunch of one-byte suboptions and the SYN-ACK contains a single suboption that is either one byte or variable length. That's what TCP-ENO is optimized for. The "things get more complicated" argument is valid because software doesn't typically have weight-and-balance-style restrictions like aircraft. Yet the 40-byte option limit is just such a hard limit. Anyway, I'm not sure we can usefully debate this point without more data, so maybe this question should be deferred until later in the process? > For instance, you can >> just barely fit a P-256 or Curve25519 DH key exchange in TCP options >> currently. If TCPINC is wildly successful, we can imagine a future spec >> that does that and squeezes the 8 most popular SYN options into a single >> byte or something. But if we waste even one more byte of option space, >> we start closing a lot of doors along that front. >> > > It seems like if that actually happens, it's also reasonably likely that we > will find some way to make the SYN bigger. I think we will get large NON-SYN options long before we get large SYN options, and even that does not appear to be particularly close to happening. I'm not sure you and I can usefully debate the future of TCP. However, if we get the extra SYN space, then the additional byte won't matter. That's why I'd rather ensure that at least one use of TCP-ENO consumes minimal space, rather than optimize something that probably won't conveniently fit in today's SYN segments anyway. And I'd like to leave the door open to a minimal ECDHE spec of the kind suggested by Watson. > That said, if you can provide an explicit example of why you might want >> multiple variable-length suboptions, you could possibly convince us to >> optimize for that case. > > > I think it's a general issue of protocol hygiene, but with that said, this > would allow you to have an optional long tiebreaker for NAT penetration. That's too general to convince me. I think we'll have to wait and see some specs that use TCP-ENO. If a non-simultaneous open scenario could end up benefiting from multiple variable-length options in the SYN segment, that might convince me. But if only SYN-ACK segments need variable length options, since they SHOULD send only one suboption, I don't think we want to optimize for the multiple suboption case. > bit to 1 at the endpoint with the lowest (public-IP-address, >> public-port-number) pair. > > > As you say elsewhere, this is common in cases of NAT penetration and > generally in NAT penetration cases you don't know your IP address > with certainty. For instance, say we have two devices with apparent > addresses: > > A: 10.0.0.1 (host), 198.51.100.1 (srflx) > B: 10.0.0.2 (host), 192.0.2.1 (srflx). > > Which one has the lower IP address? Well, assuming the RFC5737 addresses are publicly routable, obviously B has a lower IP address. If the simultaneous open is happening in any kind of application, the two sides will need to use STUN or some other service to figure out their public IP addresses and determine that they are behind the appropriate kind of NAT. They will also need to communicate their IP addresses to each other. This logic is happening anyway. We are adding a requirement that applications use this information to set the "b" bit appropriately, which is not a lot more work, but definitely not transparent. See below for more cases where setting b is not application transparent but does not require much work, either. > In the case where that was worked out most carefully at IETF (RFC 5245), > a much larger tiebreaker is used. RFC5245 uses an 8-byte tie-breaker. So to put our options in a table: +--+--+-+ | | application- | option| | works ever | transparent | space | +--+--+--+-+ |drop simultaneous | no | no | 0 | |open support | | | | +--+--+--+-+ |TCP-ENO draft | yes | no* | 0 / 1 bit | +--+--+--+-+ |TCP-use-TLS | yes | no* | 0 / 48 bits | +--+--+--+-+ |always-on RFC5245 | yes | yes | 48 bits** | +--+--+--+-+ *TCP-ENO requires applications to break the tie, while TCP-use-TLS only requires applications to set a single bit indicating they are about to engage in a simultane
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sat, Aug 22, 2015 at 11:12 PM, David Mazieres wrote: > Watson Ladd writes: > >> Let's imagine the stupidest possible protocol: each party squeezes 32 >> bytes into each SYN, representing a Curve25519 public key, and >> we compute H(agreed key || lexographically least || lexographically >> greater) . This protocol supports simultaneous open. So why can't a >> more complicated protocol do the same? > > What you describe about lexicographically least is a proprety of the > encryption spec. The question ENO addresses is how to negotiate that > spec in the first place. Suppose suboptDHE does what you describe and > suboptA is TCPINC (e.g., something derived from tcpcrypt or > TCP-use-TLS). Now consider the following simultaneous open: > > A->B: SYN ENO > B->A: SYN ENO, ENO > > Keeping in mind that the above two messages were sent concurrently, > which spec should ENO chose: A or DHE? The current draft says pick the > first spec in whichever SYN segment has the b flag set, and disable > encryption unless exactly one SYN segment has the b flag set. So 50% of the time, encryption fails between two parties both supporting the spec, when using simultaneous open. Why not impose a fixed ordering on all possible options and use the best mutually supported option, aka versioning? > >>> If by resolve simultaneous open you mean not support it, I agree. But >>> if you mean something else, then things can get tricky. I would >>> welcome a detailed design that works, but just saying "do something >>> like ALPN" is not enough detail to determine whether or not that >>> approach is viable. We'd need to see an "A -> B: ... B -> A: ..."- >>> style example with TCP flags. >> >> How often is simultaneous open used? Are there important applications >> we won't encrypt if we kill it? > > It is probably used mostly by NAT-piercing applications. The timing is > actually hard to get right if you don't have NATs involved to drop SYN > segments that would otherwise trigger resets. I wish I had more data on > this. > >>>A -> B: SYN X >>>B -> A: SYN-ACK X' which depends on X >>>A -> B: ACK X'' which depends on X and X' and might disable TCPINC >>> >>> With simultaneous open, you have two pairs of messages sent in parallel: >>> >>>A -> B: SYN X >>>B -> A: SYN Y >>> >>>A -> B: SYN-ACK X' which depends on X and Y, but not X' or Y' >>>B -> A: SYN-ACK Y' which depends on X and Y, but not X' or Y' >>> >>> So in particular B does not have the opportunity to abort TCPINC in >>> response to X', but must decide it based on X and Y. That's why TCP-ENO >>> determines the spec based only on the first ENO option sent by each >>> side. >> >> But what do you need the other ones for in that case? If they just >> contain keying material, you probably want to specialize them to that >> case. > > I don't understand your comment. By "the other ones", do you mean the > contents of packets X' and Y' in the simultaneous open scenario? With > TCP-ENO you don't need those contents (just the one bit that the option > got through and was acceptable). > > The context of the example was a response to a comment from EKR about > why not eliminate the tie-breaker bit "b" and have B chose one of the > active opener's encryption specs. I can't see a way to make EKR's > suggestion work without embedding meaningful data in X'. And the > problem I was pointing out is that the other side must commit to TCPINC > before seeing the contents of X'. > > But I may have misunderstood your question. > > For context, keep in mind that, while we would like to leave open the > possibility of embedding a DH key exchange in the SYN options, this > cannot be the only solution to TCPINC, because 32-byte curves may stop > being secure before we get large options in SYN segments (not to mention > middlebox problems of inevitably compressing SACK, TIMESTAMP, etc., to a > supported-option bit-vectorj. So we need a more general > forward-compatible negotiation option. To avoid a circular dependency, > the negotiation needs to proceed independently of the particular > encryption spec. My question is as follows: If we're willing to add half an RTT of latency because we can't put key material in the first flight, we can do the following exchange in the following manner A->B "I can speak X,Y,Z" B->A: "X, and here is my key share" A->B: "here is my key share". In the simultaneous case we can do: (using ; as sequencing mark) A->B: "I speak X, Y, Z" B->A: "I speak X,Y,Z"; A->B: "My key" B->A "My key" A and B both know that X, Y, Z are ordered, and so can agree. Now, both kinds of message are completely different, and so shouldn't be variations on the same kind to avoid attacks based on confusing SYN with SYN-ACK. > > David -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
On Sat, Aug 22, 2015 at 10:13 PM, David Mazieres < dm-list-tcpcr...@scs.stanford.edu> wrote: > > > TECHNICAL > > S 3.0. > > The variable/non-variable encoding seems suboptimal and in particular > > the restriction that only one suboption can be variable length. What > > are we going to do if two specifications wish to have variable-length > > data in the SYN packets? The specification suggests that you should > > address this by having two ENO options but that seems clumsy. > > > > I would suggest instead that if the v bit is set the next byte be the > > length. This comes at the cost of one byte for settings where there is > > only one variable-length option but is more efficient when you > > want to have multiple variable-length options, since you don't need > > to repeat the kind byte. > > Our intent is to optimize for a future in which people only need one > variable-length option. For example, the SYN can list a bunch of > options, and then the SYN-ACK can pick one of them. The current design > saves one byte, which may be quite important. But, as I note, at the cost of a byte if you *ever* want to have >1. My experience is that things get more complicated, rather than less. For instance, you can > just barely fit a P-256 or Curve25519 DH key exchange in TCP options > currently. If TCPINC is wildly successful, we can imagine a future spec > that does that and squeezes the 8 most popular SYN options into a single > byte or something. But if we waste even one more byte of option space, > we start closing a lot of doors along that front. > It seems like if that actually happens, it's also reasonably likely that we will find some way to make the SYN bigger. That said, if you can provide an explicit example of why you might want > multiple variable-length suboptions, you could possibly convince us to > optimize for that case. I think it's a general issue of protocol hygiene, but with that said, this would allow you to have an optional long tiebreaker for NAT penetration. > > > S 3.1. > > I am not convinced that a one-bit tiebreaker for simultaneous open > > is going to work. Experience with other protocols that have the > > problem of symmetry (e.g., ICE) is that this sort of thing results > > from confusion about which side is really "first". In that case, > > both sides will try to set the same "b" bit, and you will not break > > the symmetry. > > > > I believe we must either ignore simultaneous open or use a higher- > > entropy tiebreaker. > > A high-level question is whether we should completely abandon enabling > TCP?INC for simultaneous open. Yes, that would be fine with me. Another option would be to have a larger tiebreaker you only include in cases of simultaneous open, as is done in TCP-use-TLS. > If we allow encryption under some > circumstances after simultaneous open, then the next question is how to > apportion responsibility for making it work. The high-entropy solution > says make it work with high probability, but at the cost of a lot more > option space. Since simultaneous open is kind of finicky anyway, > TCP-ENO took the approach of making applications responsible for working > out the roles. For example, one plausible approach is to set the 'b' bit to 1 at the endpoint with the lowest (public-IP-address, > public-port-number) pair. As you say elsewhere, this is common in cases of NAT penetration and generally in NAT penetration cases you don't know your IP address with certainty. For instance, say we have two devices with apparent addresses: A: 10.0.0.1 (host), 198.51.100.1 (srflx) B: 10.0.0.2 (host), 192.0.2.1 (srflx). Which one has the lower IP address? In the case where that was worked out most carefully at IETF (RFC 5245), a much larger tiebreaker is used. That's obviously not information available to > TCP-ENO, which knows nothing of NATS, but is information available to an > application using STUN to broker simultaneous open. See above. As it is, the b bit is an effort to find the knee in the cost-benefit > curve. I.e., is it worth 4+ bytes of option space to make > simultaneous open work? Hard to make that case. But is it worth one > *bit* not to shut the door completely? Quite possibly. This would be more convincing if you provided an example where it actually added value. In the case you suggest above, where the sides are independently able to break the symmetry, why not simply do so via signaling? > S 3.2. > > I am unclear on why the active opener needs to have an ENO segment > > in his first ACK. Can you explain? > > There are two reasons: > > 1. Given the prevalence of asymmetric routes, it's highly likely that >situations will arise where ENO options are stripped in one >direction but not the other. Therefore, both sides need to know >not only that the other endpoint supports ENO, but that the other >endpoint can receive ENO options. If you remove the requirement >for that ACK, a scenario such as Figure 7
