TCPM meeting Meeting : IETF 82, Wednesday 30 March 2011, 13:00-15:00 Chairs : Wesley Eddy Michael Scharf David Borman Minutes : Gorry Fairhurst ============================================================== ============================================================== AGENDA A. Working Group Status B. Current WG Items C. Non WG Items ============================================================== A. Working Group Status ============================================================== WG Status was reviewed. AO NAT is under poll to determine if this should become a working group item. Joe Touch: This is in a change in TCP-AO that uses local state - there are no IANA actions. Wes Eddy: Is this for publication as Experimental? Joe: Yes. Wes: This could then be taken as an independent submission. B. Current WG Items ============================================================== New Reno: RFC3782bis (Tom Henderson) http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-01.txt Mark Allman (via Jabber): Send it to DS. Wes: There were changes to the spec. It cannot go directly to DS. It could be folded into RFC 5681 and this would need to be looked at. Mark: The changes are minor. Lars Eggert: If there even minor technical changes, this would need to be taken to PS first. An implementation report would anyway be needed, and then, if required, the same text can be taken to DS. TCP Security (Fernando Gont) http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-02 Anantha Ramaiah: There are validation statements that could be placed in a separate section. These are needed for all protocol specs. Fernando: There are still stacks that do not do all the checks. Anantha: We should put all this basic statements in one section so that people can see them all at once. Fernando: This was agreed, I could group the validation fields all together, but this makes the structure more complex. Lars: What is the intended publication status? Informational? Wes: It is for BCP. Lars: It sounds like this includes specification updates. Fernando: Here is an example: There is old text on the treatment of precedence with TCP. This is updated. Lars: The process you propose for reviewing different parts of the spec may be a good case for using the WG issue tracker. Anantha: I'd recommend reading the whole thing, and thinking about the entire document. Input validation is a basic thing that needs to be done for all protocols - e.g. length checks. Fernando: The goal is to guide implementors. Do you mean put these in a separate section? Anantha: We can discuss off-line. Anantha: The ACK number check is already done and documented in an RFC. Wes: There is RFC 5961 and this has declared IPR. Does this belong in this document? Anantha: This is up to the WG. Matt Mathis (via Jabber): It is not possible to review this document as well as it need to be reviewed Wes: Can people raise their hands if they are willing to do reviews: - approx 6 responses. Lars: I think the WG needs to examine if it has energy to complete this work. I need to see reviews. As an AD I note that the result of no reviews is that the document can not be published. C. Non WG Items ============================================================== Announcement - tcpcrypt (Mark Handley) http://tools.ietf.org/html/draft-bittau-tcp-crypt-00.txt Lars: What is meant by authentication. Does this include TCP-AO? Mark H: No, not TCP-AO. RFC1948bis (Fernando Gont) http://tools.ietf.org/html/draft-gont-tcpm-rfc1948bis-00 Matt (via Jabber): It's not necessary to keep archival text in current docs when it already exists in old docs. The appendix can be removed. Wes: Did the security AD also agree to reverting the security measures? Lars: The SecDir reviewer had no problem with MD5 for the specific use of port randomisation. This could be the same, but we would need to say this. A different question is whether we need to say a specific algorithm. There is no interoperability issue. We should recommend a strong-enough checksum. I think we can remove the historic section and refer back to the old spec in the changes section. Tim Shepherd: I haven't fully read the draft, but think HMAC is the normal recommended hash in such cases. Joe Touch: No. HMAC uses multiple hashes. Alfred Hoenes: The value "F" in the spec is a pseudo-random function, not necessarily a hash. A hash is an example, not a requirement. Joe: A pseudo-random number is not sufficient. The requirement is that someone who knows the IP address and port must not be able to guess the ISN. Wes: How many people are in favour of taking this as a WG item? - approx 10 responses. Chairs: Adoption will be confirmed on mailing list. Transparent TCP Timestamps (Richard Scheffenegger) http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-01 Anantha: How do you know that an end host sends a zero? It could be dropped or reset, e. g., by a middlebox. There can be false positives. Richard: If the validation fails, it falls back to the default. Fernado: Do you know of any modern stack behaviours that would result in a failure? Anantha: It doesn't matter, the robustness principle applies. Richard: It uses the reflected timestamp. Anantha: Can we not directly use the clock-tick, rather than encoding the value? Tim S: I think we need a wider range of values? Do you plan to vary the clock rate based on the negotiation? Andrew Yourtchenko: Maybe this is a good time to discuss larger options space for TCP. TCP Fast Open Proposal (Yuchung Cheng) http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-00 Andrew Y: Is there a reason why you didn't include the TS in the cookie calculation? Is the cookie valid for an unlimited time? Yuchung: We did think of that. The cookie can exist for longer time scales. Murari Sridharan: What happens if you are behind a public NAT, and all have the same IP? Jana Iyengar: Can the cookie be reused? Yuchung: A setup handshake is needed. Lars: With TFO you have an additional attack vector. Can you use SYN-cookies with TFO? Yuchung: No. You can't decode the state for SYN cookies. You can only do one at a time. Lars: The draft proposes a limit on the number of connections? How large will this limit be? Yuchung: Of the same order of magnitute like the SYN backlog. Lars: Bill Simpson has a draft on TCPCT that focusses on repeat connection instances with a time between events. Fernando: Do you impose a limit on the volume of data in a SYN segment? Note that one could send 64KB with fragmentation. Joe: If it is fragmented, you'll never see this at the TCP level. Andrew S: When there are many users behind the same NAT then what happens? Yuchung: They all get the same cookie. Joe: Data can always go in the SYN, the difference is when you deliver it to the application. Data in SYN is not a new thing. Yoshifumi Nishida: Can you keep the TCP connection? This may be a better solution with less overhead. Yuchung: There is a limit on server resources, at least for HTTP server state. Yoshifumi: You may want to keep only the TCP connection status. Joe: It is different, if you keep the connection open, you need to know the port numbers at the application. Lars: Bill Simpson has a proposal that addresses one use case. I would not like to see two cockie exchange proposals. It would be nice to see a solution that addresses both cases. Yoshifumi: Bill did not want to keep server state. Proportional Rate Reduction for TCP (Nandita Dukkipati) http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-00 Chairs: Please send comments on this draft to the mailing list. Using the ECN Nonce to Detect Spurious Loss Events (Michael Welzl) http://www.ietf.org/mail-archive/web/tcpm/current/msg06380.html Chairs: No time for this talk at the Prague meeting. Please send comments to the mailing lost.