TCP Maintenance & Minor Extensions IETF 75 - Stockholm Chairs: David Borman & Wesley Eddy Note-Taker: Dave Craig (Qualcomm) WG Document Status - 2581bis update o Lars Eggert: update fixed typos submitted and going to RFC editor - Would like more reviews on Early Retransmit - 1323bis o WGLC hummed ok TCP Authentication Option Status - Soliciting more comments, only 2 submissions so far - Issues raised – ICMP handling o No need to do more than IPsec - Issue tracker issues 1-16 addressed - TODOs from IETF74 addressed - New consideration: NAT interop, support flags to specify whether to zero out address and port before computing hash at the cost of entropy - Looking for direction on whether all TCP implementations must/should implement o Lars Eggert: suggested adding text that TCP MD5 implementors must upgrade to the new authentication option o Greg Lebovitz: asked whether this explicitly deprecates TCP MD5 ? Yes o Greg Lebovitz: Then implementers will already know to upgrade. Can’t require all implementations to implement TCP authentication option o Lars Eggert: tcp-ao cannot obsoletes TCP MD5 since o Greg Lebovitz: Cannot require implementers implement something that’s an option o Joe Touch: That’s not how SACK went in o Lars Eggert: Need to add tcp-ao to roadmap and that should be enough guidance to implementers o Lars Eggert: There’s a request to publish and include a pointer to an informational RFC for draft-monica ? Joe Touch: As long as there’s language there that implementers don’t use experimental code point 254 o Greg Lebovitz: Doesn’t draft-bonica’s reference to tcp-ao make them already go into the RFC editor queue at the same time? o For interop with existing code base, don’t we need to support code point 254? o Lars Eggert: need to keep definition of 254 in draft-bonica as a heads-up o Joe Touch: did not o Greg Lebovitz: Would like to see a solution to the NAT interop problem, design as presented looks ok, but would like to see text. Worried about time pressure. ? Joe Touch: Should not be a signicant time impact o Eric: It is a mistake to attempt to address NAT interop, not addressing all security concerns o Greg Lebovitz: Would like to break out NAT interop as a separate RFC. An additional RFC should spin quickly ? NAT interop as o Take it to last call now as o Raise of hands on not including NAT and going to last call, working group agreed TCP-AO Crypto Goo - Require two hashes supported as a MUST - KDF, inputs for hash, dropped boundary marker o Ekr (from mailing list): Output length puts a requirement on tcp-ao ? Joe Touch: Split between tcp-ao-crypto document and tcp-ao should be an API. ? Greg Lebovitz: Not sure understand concern, but I’ll take concern up with him. Agrees that opaque data blocks should pass through an API from tcp-ao to tcp-ao-crypto - AES-128 requires 128 bits for key, so zero pad user input to make 128 bits and then submit to AES-CMAC to generate the key for running AES-CMAC o Cryptographer heartburn, security Ads flip-flopping, but currently have their support o Andrew Lange: Why not use zero pad user input as key and lop off user input longer than 128 bits, but ok with technique as presented o Joe Touch: Two different keys differing only after 128 bits will be the same o Greg Lebovitz: 4615 uses this double hash - Concern that reviews give suggestions based on a new employee trying to implement tcp-ao-crypto o EKR: objects to SHOULDs on UI on naming - Changes to come o Unless there’s more changes this week, document will spin at the end of the week to become a working group document - WGLC queued for mailing list Advertisment: Authenticated Routing Protocols Roadmap - Should there be an interface for TCP to support automated keying Security Assessment of the Transmission Control Protocol (TCP) - Includes an analysis of every bit in TCP header, duplicates some information in other RFCs - Interest expressed on mailing list included implementers willing to help with document, also those interested in starting from scratch - Rough consensus to adopt as a working group item, but have to exclude non-maintenance recommendations in the draft. o Lars Eggert: Document targeted as BCP, is that right target? BCP may be too strong a target, since it requires IETF consensus o Wes Eddy: Author is ok with informational target o Joe Touch: There are too many informational RFCs. Make a stand and put together a recommendation to prevent TCP from falling . Having deployed implementations do not mean that TCP is safe. o Lars Eggert: Securing TCP will be the largest work item for tcpm. Going through Security Area and Operational Area will slow progress and require a lot of support. TCPM needs strong consensus to take this up. o Wes Eddy: The amount of documentation and tutorial o Greg Lebovitz: WGs don’t need drafts to 100% right to become WG items. Is there enough oomph to finish it? o Joe Touch: TCPM is the working group to give implementers information on how to deal with potential attacks. o Greg Lebovitz: Target should be BCP. Should draw a conclusion and give guidance to implementers. o Dave Borman: Supports BCP target. Not sure whether to start with document or a new outline. o Wes Eddy: supports Dave’s conclusion o Andrew Youtchenko: Supports BCP with pro/con discussion. o Raise of hands points to BCP, but final will go to list o Raise of hands to start with clean slate or gont submission, support for starting with new outline, but final will go to list Make TCP more Robust to Long Connectivity Disruptions - Reviewed changes from draft-zimmermann-tcp-lcd-00 - Problem of Long Connectivity Disruptions o Connectivity loss greater than RTO causes backoff and TCP slow to recover - Solution: undo one RTO backoff when receiving ICMP destination unreachable - Issues to be resolved like continuing backoff when there’s explicit congestion notification - Detailed algorithm presented o Joe Touch: Should not interpret sequence number from ICMP if router does not return them in a timely manner. How handle false positive and negatives? ? Should only have one segment in flight during connectivity loss ? Miniscule chance of “wrapped sequence number”, requires short connectivity loss followed congestion loss inaccurately stopping backoff - Enumerated features and special cases o Retransmission ambiguity, can use timestamp to figure out which segment corresponds to an ICMP retransmission - Patch available for Linux - Wes Eddy: Soliciting opinions on the mailing list as to whether to pickup as working group item Tuning TCP Parameters - Desire to improve throughput over TCP - Update InitRTO recommendation made in RFC 1122 of 3 sec to 1 sec o Gorry Fairhurst: Solaris set initRTO to 1 sec and broke connections over long delay like satellite o Joe Touch: Uses wireless data that can have RTTs greater than 1 sec, and users can hop onto this link using Wifi and not realize that wireless link is in their path o Lars Eggert: Bit torrent clients can queue up 2-3 seconds of delay on different connections o Mark Allman (jabber): How would a stack detect a large RTT path that requires a larger value of InitRTO? (Joe Touch also wanted to know) o Maintain statistics to prime InitRTO o Gorry Fairhurst: Ethernet and wifi access can vary a lot depending on the amount of usage/congestion o Mark (Jabber): Which connections are used in statistics for InitRTO o Aggregate statistics per subnet - Presented world-wide RTT distribution based on SYNACK to query to show most connections to Google servers have RTT <1s - Increase InitCwnd from 3 to 4, median HTTP response size has increased, so o Joe Touch: Is the user going to notice 1 RTT vs. 2 RTT latency. Percentage difference not significant enough. o Andrew Yourtchenko: HTTP/1.1 should reuse connections? Why is response size so small. o Joe Touch: Results should include data sent over lifetime of connection instead of just HTTP response. Suggests follow up with group to discuss safety in changes off line and mailing list. Using TCP SACK Information to Determine DupAcks for Loss Recovery Initiation - Use SACK to identify out of order delivery instead of incrementing dupack counter - Request for interest from working group? Queued for mailing list discussion, since there was not enough readers in the room.