Draft: draft-ietf-taps-interface

Commentary: If I understood this right : if this is even a reasonable source ... then what this attack does , is to take the TCP connection away underneath the application 's feet . Then , an application may still expect parts of a message but they may in fact never arrive because the Connection is in fact gone . Does n't this mean that this exploits a detachment between TCP and a protocol atop TCP , which does n't inform the application of the arrival of a FIN ? In this case , I do n't understand the concern raised by in : the delivery of " outstanding partial messages " means that the receiver has them in the buffer , and then a FIN arrives - upon reception of the FIN , these " outstanding partial messages " should be delivered . That seems right to me . I may easily be completely off track ! But either way , also noted in that the attack should be described , so I do n't think that this PR satisfies the issue as it stands . 
 A contrived example of the problem is if you intend to execute " rm -rf /some / path " and it somehow gets truncated to " rm -rf / " . Protocols need to be designed in such a way that they deal properly with partial messages . I think the proposed text is fine . 
 Aha ! That 's completely different than my reading of the Wikipedia page . Then that 's fine , I also agree . 
 My 2c : You can always design bad apps : I do n't think transports should be designed to do application data checks ... applications should do that on the data they send . 
 The new text seems to say what it should , although I do n't see what this is an " attack " , it would happen naturally when communications breaks . 
 Maybe we should discuss this . I see the need for something here as twofold : users that they should not ignore the API - enabled distinction between full and partial messages . sure implementors properly classify partial messages as partial , so truncated messages ( whether resulting from an attack or not ) are presented to the application in a way that it can respond appropriately . Specifically because TAPS provides message and layer abstractions ( for security and framing ) , it 's imperative that the implementor of each stage of the pipeline preserve the partial / full message distinction because unlike applications built on top of TCP sockets the application author may not have the ability to detect a partial message because windowing / framing at the lower layers are n't exposed to the application . Based on this conversation , it sounds like we do need the text to make this a bit clearer . 
 I think this is useful to keep in . Security considerations are always good to point out . Happy to take suggestions for clarity . 
 Under the doc says : Emphasis mine . This is a key enabler of truncation attacks , so the interface should only do this if the application is well aware of the implications of receiving partial messages and/or if the partial nature of the message is made clear to the application . 
 Perhaps would also need to spell - out what constitutes a truncation attack ? 
 Should go into API security considerations to tell  to be careful to not assume that when a connection closes that their received data was complete and/or well - formed . 
 This LGTMLGMT with additions
Paragraph (version B):
Applications should also take care to not assume that all data
received using the Transport Services API is always complete or well-
formed.  Specifically, messages that are received partially receive-
partial could be a source of truncation attacks if applications do
not distinguish between partial messages and complete messages.