[tcpm] Comments on TCP-AO Draft

Hi All,

Here are some comments on this draft.  Since this is the last full draft I have, I've focused the comments on this iteration.   The short version:  This document needs significant work.

Abstract:  The draft begins to contextualize the place where TCP-AO is operating.   However, it does not pay any attention to draft-bonica, or the 3+ years of deployment experience with draft-bonica.  Proper contextualization is important to evaluate the draft and its changes. 

Abstract: Update to TCP MD5 needs a reference at the end of the Abstract section.

Abstract: Define "MACs" - this is the first time it's used, and although we can hope that people know which ones we're talking about, it wouldn't hurt to write "Message Authentication Codes (MACs)" out.

General Comment: There is no security policy explained in the draft: What are we protecting against?  From whom are we protecting? For how long?  It is critical to know who the threat(s) are.

General Comment: This draft badly needs a "Deployment Considerations" section, that shows how to operationalize the techniques, and situates things such as migration from older techniques to newer ones.  Especially important are transition mechanisms. 

Introduction: we should defined "cryptographic key management" as in "...not the framework for cryptographic key management." And explain why the draft makes this recommendation.

Introduction: End of 2nd paragraph, reference to Be07 should be normative - if the draft is to fulfill the requirements, those requirements should be not subject to a moving target.

Introduction:  The draft is very blithe about recommending IPSec and IKE, without providing any context why this is a good idea, or why it has never been deployed.  There are significant issues with using IPSec for routing (complexity, reduced convergence times, relying on security layers for routing functions, etc.)  These issues need to be documented, and discussed, before as the IETF, a recommendation should be made. 

Introduction: Last paragraph - "TCP MD5 does not support any changes to the connection's security..." Well, the draft may not consider this, however, if you get the keychange timing done correctly, in fact, you can roll the keys.  It's a kludge, but it would be inaccurate to state otherwise.

Exec Summary:

"Allows TCP-MD5 to be used..."  - Why is this here? 

"TBD-WG-MACS" - MACs MUST be specified, in the draft. 

Ends of "Allows rekeying" section - TCP MD5 rolling comment is at odds with the end of the introduction, it should be explained how this works.  Also, why MD5 could lose packets also needs to be explained, and why new techniques do not suffer from this limitation.

"Provides more detail in how this option interacts with TCP's states, event processing, and user interface" - more detail that what?  Much of this is implementation specific.  Especially the user interface parts.  This draft tends to munge what is necessary for interoperation (the standard), and the way one might implement that internally (implementation details.)  Providing a reference state machine or details are useful, but shouldn't be conflated with the standard spec.

"Provides automatic key rollover" - is this section referring to key rollover via keychains?  key diversification techniques? 

"Proposed option is 3 bytes shorter than" - why should we care?  What do those 3 bytes buy us?

"Does not authenticate ICMP messages (some may be authenticated in IPsec..." - is it also lighter weight, and better suited to router protocol operation and deployment. 

1.4.1: " IETF-72 topic" sections "No current consensus was reached on this topic, so no change was made."  This is a real problem -- the logic is deeply flawed.  Allow me to restate: One author of this document has appointed themselves the arbiter of consensus.  This author disagrees with other people, and therefore no "consensus" can ever be reached, so the default case this author has chosen is to keep things they way they like it.

3.2 - "in the sprit of SP4" - why is this relevant to the document? 

3.2 - The whole of ESN gets introduced without much prelude or contextualization.  Since this is something new for this draft (correct me if I'm wrong.) It really needs to be better contextualized.  In fact, since this is something that may have utility outside of TCP-AO, it ought to be documented in a separate draft, probably as a separate option.  It has an impact on the TCP state machine that goes beyond a bigger value to prevent replay.

"TCP Data in Network Byte Order" - We really do need to specify which MAC's were going to use.  Otherwise, the draft isn't very useful.

"When options are excluded, all options..." - How is this indicated on the wire?  I'm guessing that the plan is to do this with configuration on each end.  This is a recipe for misconfiguration and confusion.  Putting a bit in the option makes this much easier to troubleshoot, especially for sessions between providers. 

"The implementation of ESN is not specified in this document..." - Does this mean that there is a forthcoming draft that specifies how ESN is to be used?  

"Computing connection keys from TSAD key entries" - This section is a non sequitur , there needs to be framing and introduction, as well as some sort of segue from the section partly documenting ESN.

"Conn_key = MD5(TSAD_key, connblock)" - why is MD5 used here?

"For SYN segments..." - Implicit special cases are bad, as a matter of design.

"... extremely unlikely" - how unlikely? We can put the number in there, since the definition of "extremely" tends to change over time. 

Section 6 - Security Association Management - Define a TSAD: What does it do?  Why does the draft propose this construct?  

"A TSAD implementation MUST support at least two keyIDs per connection per direction, and MAY support up to 256." - why only two?  wouldn't we imagine most TSAD's supporting 256?  It's not much of a burden, and making a recommendation for two in an example implementation may lead to some bad designs.

Somewhere we need to explicitly state that 0 is a valid keyID.

IKEv2 Transform Type -- why are we putting a dependency on IKE for this?  The protocols can and should be completely orthogonal to each other.  Putting change-dependencies in on updating IKEv2 registries will limit the protocols utility and agility.  

"...single host there should only be a single database..."  - this seems at odds with sections later in the document.  It also excludes virtualization and multi-level secure systems.

"..omit an explicit algorithm ID..." -- I've said this before, this is a BAD IDEA^tm. The protocol utility of doing this is minimal (1-bit increase in search space), and the operational complexity goes up.  Not to mention, it makes it operationally incompatible with existing implementations. 

"It is presumed that a TSAD entry affecting a particular connection..." - this section is at odds with what id done elsewhere.  If the document is going to provide implementation advice, then it needs a state machine here to show how one might handle key destruction, process conflict, race conditions, etc.

"Users are advised to not inappropriately reuse keys" - Why is there this throwaway line in here?  If we look at 3562, we see there are three recommendations:
o Key lengths SHOULD be between 12 and 24 bytes, with larger keys having effectively zero additional computational costs when compared to shorter keys. 
o Key sharing SHOULD be limited so that keys aren't shared among multiple BGP peering arrangements. 
o Keys SHOULD be changed at least every 90 days.
What are the recommendations for each of these?  Why are we continuing to use them here?  With key diversification, perhaps the same root key can be used (assuming we document that a peer sharing that key could potentially create an attack on reboot).  Also, with stronger MACs do we need to change keys every 90 days?  Are 12-24 byte keys appropriate for HMAC-SHA1-96 and AES-CMAC-96?

"TCP segments with TCP-AO but not matching TSAD entries MUST be silently accepted." - Accepted?  Does this have to do with the proposed order-of-match logic internal to the end systems?

"Additional reductions in MAC validation can be supported by using a MAC algorithm that partitions the MAC field into fixed and computed portions."  - Do we have examples of these MAC algorithms?  Wouldn't adding a "fixed" portion to a MAC algorithm rather defeat one of the MAC algorithm design goals?  Perhaps one of the security experts could comment on this.

"In the default case, where only a single key is used at a time..." - The document should elaborate on what it means here.  Is this a recommendation that the TSAD only support a single key?  Why would there be invalid keys used?

"... benefits from congestion control support for temporary path outages." - References?

SACK recommendation - Why?  Is there something special about TCP-AO, and not regular TCP sessions? Or is this a recommendation to use SACK for all TCP segments?

"Implementations are encouraged to keep keys in a suitably private area."  I agree, but what does this mean? What is suitable for this protocol?  What is private?

"Keys should not be shared across different hosts, because this could compromise the keying material itself." - Doesn't this defeat the purpose?  This is a shared-key cryptosystem.

"Note that when TCP MD5 is required for a connection, it must be used [RFC2385]" - This is rather confusing.  This was written in one time and place, and there is real-life versus standards-life.  We need to make recommendations for the former.  Is the advice that only MD5 or AO be used based on a line in a standard published 10 years ago, that documented an even older implementation??

Section 10 - The option to calculate options or not should be in the packet.  If not, there will be a lot of broken connections out there, and people who have no idea why they are broken.

Section 12 - reference to Be07 should be Normative. 

Section 13 - this section shows a limited knowledge of deployed routing protocols, especially in the comparison to what the document believes is the preferred solution of using IPSec.  In deployment, there is both the TCP TTL hack, and the extensive use of edge and system ACL's to provide multilayer security.  

"TCP-AO does not expose the MAC algorithm used to authenticate a..." - Again, this is a BAD IDEA^tm. It offers minimal expanded search space for the algorithm (1-bit).   It also violates fundamental security design:  The security should be in the key, not in the obscurity of the algorithm.   Not carrying algorithm ID results in more downtime due to opaque system operation.  

"ICMP messages of Type 3, Codes 2-4" - This needs to be expanded.  People do not have ICMP type codes memorized.

"To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2" - Again, bad idea.  This creates an unnecessary protocol linkage between the spaces.  Not to mention a development, test and operational headache -- "This protocol supports 2 MAC types, and yet the codes are "17" and "153" - WTF??"

Andrew