Clarification of sender behavior in persist condition (draft-ananth-tcpm-persist-00)

1
Clarification of sender behavior in persist
condition (draft-ananth-tcpm-persist-00)

• Murali Bashyam
• Mahesh Jethanandani
• Anantha Ramaiah
• IETF 72
• Dublin, Ireland

2
History

• draft-mahesh-persist-timeout-02 covered two
  issues
• Sender behavior in persist condition AND
• DoS scenario that is caused by the sender
  behavior
• Chairs suggested splitting the draft into two
• This is first of the two drafts
  (draft-ananth-tcpm-persist-00)
• Second draft (also informational) is in the works
• It documents DoS scenario
• Outlines possible solutions and their pros and
  cons

3
What does this draft cover

• Covers clarification about sender behavior in
  persist condition
• Does NOT talk about DoS scenario and any possible
  solutions

4
What is the confusion about sender behavior?

• RFC 793 Section 3.8 states The user may CLOSE
  the connection at any time on his own initiative,
  or in response to various prompts from the TCP
  (e.g., remote close executed, transmission
  timeout exceeded, destination inaccessible).
• RFC1122 Section 4.2.2.17 says that A TCP MAY
  keep its offered receive window closed
  indefinitely. As long as the receiving TCP
  continues to send acknowledgments in response to
  the probe segments, the sending TCP MUST allow
  the connection to stay open.

5
Clarification

• Consensus reached in the tcpm mailing list
• Current verbiage in RFC 1122 is causing confusion
• Clarification needed on sender behavior
• Sending TCP can close the connection in persist
  condition

6
DoS Scenario

• In persist condition, sending TCP continues to
  hold data indefinitely
• Could lead to buffer and connection resource
  exhaustion
• Second draft describes potential solutions in
  detail

7
Next steps