Subject: [tcpm] Comments on TCP-AO Draft

From: "LANGE Andrew" <[email-masked]>
Date: Mon, 17 Nov 2008 12:51:15 -0600

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
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 17 Nov 2008 14:06:10 -0600

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of LANGE Andrew
>Sent: Monday, November 17, 2008 1:51 PM
>To: [email-masked]
>Subject: [tcpm] Comments on TCP-AO Draft
>
>

There are a lot of good comments here that will strengthen
the document.  One of them that concerns the wire-format rather
than text additions, clarifications, and changes that are
needed, which we should address quickly is:

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

There was logic given to support each side of the argument.  My
understanding of the summary for each position is:

(position 1 - "include") Including information like algorithm ID
and k-bit is BAD because it aids in debugging of implementations
and of configurations.

(position 2 - "don't include") Including this information is BAD
because it can expose information about the security parameters.
It doesn't aid in debugging of configuration because operators still
have to call each other in order to read off and verify keys.

There seemed to be more people around position 2 than position 1,
but we should flag this and ask during the meeting, as well as
open this up on the mailing list to see what people prefer.  We
need to pick one and move on.

As an individual, and not a co-chair, I'm in the position 2 "don't
include" camp.

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Nov 2008 15:20:45 -0800

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

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.

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

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

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.

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

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.

- ------------

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Mon, 17 Nov 2008 17:28:04 -0800

inline...

>and k-bit is BAD because it aids in debugging of implementations

Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? 
I'll assume yes.

>need to pick one and move on.

I concur with your recollection about the two positions above. I also 
concur with your recollection that there was more people (not 100% 
consensus, but more) around Position 2 than 1. The argument I made 
went something like this, and was based on lots of years of debugging 
interop issues in both IKEv1/ESP and IKEv2/ESP:
  - there is only the case where the connection will be discussed out 
of band by system admins before a first connection is made. At that 
point, there will be some agreement about config choices.
  - if the connection doesn't work, you double check your config 
matches your agreement of config choices.
  - if the config matches the agreement, then you can try the other 
algo, just in case you misheard that part.
  - if it doesn't work, then you have to pick up the phone and call 
the other guy to double check config parameters.
  Conclusion: having the bits on the wire about the config elements 
doesn't help practically, and contradicts the basic security 
principle of hiding as much about the SA as possible.

So I am also support Position 2.

Gregory.

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Mon, 17 Nov 2008 17:33:43 -0800

inline again...

>> >incompatible with existing implementations.

BTW, in the reference above, in the newly posted
     <http://tools.ietf.org/html/./draft-ietf-tcp-auth-opt-02>draft-ietf-tcp-auth-opt-02
this comment regards section 1.3.1, not 1.4.1.
Hope it helps,
Gregory.

>I concur with your recollection about the two positions above. I 
>also concur with your recollection that there was more people (not 
>100% consensus, but more) around Position 2 than 1. The argument I 
>made went something like this, and was based on lots of years of 
>debugging interop issues in both IKEv1/ESP and IKEv2/ESP:
>  - there is only the case where the connection will be discussed 
> out of band by system admins before a first connection is made. At 
> that point, there will be some agreement about config choices.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 17 Nov 2008 19:40:15 -0600

>From: Gregory M. Lebovitz [mailto:[email-masked]] 
>Sent: Monday, November 17, 2008 8:28 PM
>To: Eddy, Wesley M. (GRC-RCN0)[VZ]; LANGE Andrew; [email-masked]
>Subject: Re: [tcpm] Comments on TCP-AO Draft
>
>> > ...
>> >

Yes; thanks for catching that ...

---

From: "LANGE Andrew" <[email-masked]>
Date: Tue, 18 Nov 2008 15:34:10 -0600

Hi Wesley,

We can certainly discuss the issue.  Although there seems to be a typo below. Shouldn't the include option say that it is GOOD to include the data?

I've also includes some elaboration of the arguments inline.  Perhaps an explanation of where this requirement is coming from would help. 

<< elided >>

Elaboration: Including this information allows debugging, and significantly aids in drilling down to the real problem.  I have had a direct hand in operating, engineering or architecting five major ISP networks, before working for a vendor.  Since then, I've been involved in a number of others.  The simple truth is that any additional information is very helpful, especially at 4am, when you've rebooted a peering router, and cannot explain why some of the peering sessions are up, and others aren't.  Misconfigurations take many forms, and being able to look, and see immediately that, during the reboot the local system failed back to a saved config with "ignore TCP options" or "use HMAC-SHA-1-96", and the other side is sending "use AES-128-CMAC-96" clears up the need for a phone call.  Also, in reality, it is rarely a simple as a phone call.  Tickets are created, phone calls are made, escalations happen, all the while traffic is misrouted, or not flowing at all.  The longer the outage, the bigger the bottom line impact. Having this information around reduces the impact, and shortens or eliminates the phone call.  Having been there at 4am, troubleshooting these sorts of things in the past, I know this.  And it hold true across operators. 

Elaboration: Originally I was also of this position.   However, I came around when I considered the operational impacts.  We need to make this protocol as operator-friendly as possible.  That is why it is being created to begin with.  We shouldn't lose sight of deployability and maintainability in the quest to shorten an option by a byte (especially when we gain 3 from MD5 to start with.)  Also, we have had many strong security experts, such as ekr and Brian Weis (gentlemen, correct me if I'm misquoting you) say that putting algorithm ID in the packet does very little to make it harder for a bad guy to attack the session.  To be specific, the attacker has to be a man-in-the-middle to see the ALG ID to start with (whereas blind attacks are probably more likely).  In addition, the search space would be extended by a single bit.  We're already using very strong algorithms, and have the agility to add more.  Search is already infeasible with known state, and if that changes the right approach, and the secure approach is to introduce another algorithm. 

Elaboration: I haven't taken a poll, but we do need to keep in mind, that operators tend to be poorly represented, and they are the people who are going to be using this.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Nov 2008 15:40:03 -0600

At Tue, 18 Nov 2008 15:34:10 -0600,
LANGE Andrew wrote:
> because it can expose information about the security parameters.  It
> doesn't aid in debugging of configuration because operators still
> Elaboration: Originally I was also of this position.  However, I
> came around when I considered the operational impacts.  We need to
> make this protocol as operator-friendly as possible.  That is why it
> is being created to begin with.  We shouldn't lose sight of
> deployability and maintainability in the quest to shorten an option
> by a byte (especially when we gain 3 from MD5 to start with.)  Also,
> we have had many strong security experts, such as ekr and Brian Weis
> (gentlemen, correct me if I'm misquoting you) say that putting
> algorithm ID in the packet does very little to make it harder for a
> bad guy to attack the session.  To be specific, the attacker has to
> be a man-in-the-middle to see the ALG ID to start with (whereas
> blind attacks are probably more likely).  In addition, the search
> space would be extended by a single bit.  We're already using very
> strong algorithms, and have the agility to add more.  Search is
> already infeasible with known state, and if that changes the right
> approach, and the secure approach is to introduce another algorithm.

I don't think there's any real security value to hiding the identity
of the MAC algorithm. I leave the question of whether shaving the
byte is worth doing to the TCP experts.

-Ekr