Re: [tcpm] Comments on TCP-AO Draft

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Andrew,

LANGE Andrew wrote:
> 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.

FWIW, this note apparently addresses a preview draft between -01 and
- -02. The -02 update has been available since the cutoff date, two
weeks ago.

Some further notes below...

Joe

> The short version: This document needs significant work.

The list below suggests a number of changes which should be able to be
incorporated in a week or two.

> 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.

That can be addressed in the intro.

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

My understanding is that abstracts don't have references in them; I can
confirm this with the RFC Editor on this point

> 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.

Will do.

> 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.

Will do.

> 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.

The draft does have some of these issues already described, but it would
probably be useful to have a separate discussion that summarizes the
issues and expands on them.

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

Will do.

> 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.

My understanding is that normative references must be standards track or
equivalent (e.g., from IEEE), whereas Be07 would be informational if
published. We haven't updated Be07 because it may be sufficient to cite
it (for due credit) and just point down to the later section that
contains most of it's info anyway.

> 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.

Will do.

> 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.

Will do.

> Exec Summary:
>
> "Allows TCP-MD5 to be used..."  - Why is this here?

It addresses the transition issue you note above.

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

That's clearly noted as needing to be fixed; we're still waiting for the
specific algorithm. We may be able to determine that this week.

> 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.

Will fix.

> Also, why MD5 could lose packets also needs to be explained, and
> why new techniques do not suffer from this limitation.

Will address.

> "Provides more detail in how this option interacts with TCP's states,
> event processing, and user interface" - more detail that what?

Than TCP MD5; that is the section in which the comment appears.

> Much of this is implementation specific. Especially the user
> interface parts.

Agree that the user interface part needs revision to avoid focusing on
implementation issues.

> 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.

The event processing and state issues, however, have been noted numerous
times as relating directly to RFC793, not to an implementation.

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

Will fix; it should say that we use extended sequence numbers, not key
rollover (which was originally added to address sequence number rollover).

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

That is addressed in Section 7.6. Depending on the options and padding
used, it could buy us another option or another SACK block.

> "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.

Will add as a benefit.

> 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.

See Wes' post on this issue.

A draft of this document was circulated to the off-list group - yourself
included - Oct 10.  The text on these issues was coordinated with the WG
chairs, and we received no feedback on this until your note today.

I appreciate your concern with the text, but not with your concerns
about the process by which it appeared in the current draft.

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

This issue was raised by others; I can find out who if you're interested.

> 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.

It is designed in such a way as to be interpreted from the
incoming/outgoing packet; there is no direct interaction with TCP's
state machine required.

I agree this may be of larger utility, and I'll prepare something for
the next IETF on this. Thanks for noting that.

> "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.

Already noted above.

> "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.

It is not indicated on the wire for the same reason the algorithm isn't
indicated - it is already required to be coordinated at the endpoints.
Wes sent a separate note on this to the list, and this will be discussed
in public at the meeting.

> "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?

You noted above that we should avoid implementation issues; that's all
this statement reiterates. As you noted above, a separate document can
be developed to discuss the more general utility of ESNs.

> "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.

Will fix.

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

Being fixed this week.

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

This is explicit, not implicit. It is required because a SYN indicates
the source's ISN but the receiver's ISN cannot be known at that point;
we're just recognizing the existing handling of ISN values by SYNs, not
creating anything new.

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

Will do.

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

This can be explained further in the document.

> "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.

It was a conservative assumption of a MUST; if the WG feels that it
should be increased, it can be changed.

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

See Section 6:
               >> A KeyID MUST support any value, 0-255 inclusive. There
               are no reserved KeyID values.

> 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.

We're not depending on IKE; we're depending only on its registry,
because we don't see a reason to ask IANA to create a new one. We can
instead ask IANA to create a new one.

> "...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.

Will fix. The point is that there is a single database for a given IP
address; a database can cover multiple IP addresses. There can't be two
databases for a single IP address.

> "..omit an explicit algorithm ID..." -- I've said this before, this
> is a BAD IDEA. 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.

TCP AO has no existing implementations since it has not been completed.
We have already been reminded in various off-list discussions that we
are not required to be compatible with the draft-bonica solution, and
there are numerous other ways in which this draft is not compatible with
that solution anyway.

> "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.

We're updating this to avoid implementation information, but need to
retain information that defines the behavior of the TSAD, e.g., as above.

> "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?

We can reuse 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?

Will resolve.

> "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?

This means that gratuitous signing of segments will not cause them to be
dropped. We could change the requirement to 'drop if no key known', but
it seems like if you care about a source you would put in a key.

> "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.

This was in response to an issue raised by Ran Atkinson, and he agreed
to the response. Such a MAC algorithm would be to overwrite the lowest
byte of an HMAC (e.g., from HMAC-SHA256) with a fixed byte. It does not
weaken the HMAC any more than would truncating the HMAC - e.g., if you
truncate to 80 bits, then add another 16 of nonce, then the nonce can be
used for fast triage. I can add that example if it seems useful.

> "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?

Will fix.

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

Will add (it's just TCP congestion control).

> 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?

There's already a recommendation to use SACK in general. SACK helps here
to avoid reMAC'ing segments already received; given the overhead of the
MAC algorithms, this seems useful. Others already noted we should
explain this. In summary, we'll fix this to basically say "this is no
different from existing TCP recommendations, and the benefit from SACK
helps even more here".

> "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?

That's implementation advice. We can omit it.

> "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.

This will be clarified to say "across hosts not directly communicating".
It's general key reuse info. We can omit it if preferred.

> "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??

Yes, we're quoting existing requirements. It can be clarified; all it
means is that if you install a key for a socket pair in TCP MD5, you
don't accept segments that aren't signed.

> 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.

We've already explained several times that the reason a connection
breaks is determined by information at the endpoints already - the key,
the option inclusion info, etc. That already has to be confirmed; having
any of that info in the packet does not help.

> Section 12 - reference to Be07 should be Normative.

See note above.

> 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.

That section can be clarified to explain that we're talking about
authentication of TCP segments and protection from spoofers that could
be on or off-path. The TCP TTL hack can be added.

Can you clarify the issue of ACLs? How do those protect TCP connections?

> "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.

I can reword this throughout as "does not indicate" rather than implying
a benefit by using the word "exposed".

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

Will do.

> "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??"

Already addressed above.

- ------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkh/E0ACgkQE5f5cImnZru8NwCffaCIxSsbJIgBEqST3HKyZ0Nu
WFcAoIpV6clUYqM95MPKTWNR/gNsZtFM
=WFpA
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm