Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 1 May 2012 08:46:47 -0700

On Mar 27, 2012, at 7:39 AM, Joe Touch wrote:

> Comments attached below.
> 
> Joe
> 
> On 3/26/2012 9:15 AM, [email-masked] wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF.
>> 
>> 	Title           : Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide
>> 	Author(s)       : Mahesh Jethanandani
>>                           Keyur Patel
>>                           Lianshu Zheng
>> 	Filename        : draft-ietf-karp-routing-tcp-analysis-01.txt
>> 	Pages           : 17
>> 	Date            : 2012-03-26
>> 
>>    This document analyzes BGP, LDP, PCEP and MSDP according to
>>    guidelines set forth in section 4.2 of Keying and Authentication for
>>    Routing Protocols Design Guidelines [RFC6518].
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01.txt
> 
> ----
> 
> - the document name and title are misleading

If you do not like the title please suggest one.

> - the document structure is misleading
> in both cases, transport and network vulnerabilities are confused with routing layer vulnerabilities; the doc should be very clear about what layers are being analyzed at each step
> 
> - TCP MD5 is cited throughout and noted as weak, even though it is obsoleted by TCP-AO.
> This should be made clear for every routing protocol that still uses TCP MD5 where that is mentioned, i.e., first that TCP MD5 is obsoleted, and second that TCP-AO fixes the issues of note with TCP MD5 already.
> 
> - Sec 2.2 mentions reasons for not rekeying secure TCP connections
> i.e., that they would generate a reset, but this is not the case for TCP-AO, nor was it for TCP MD5. When a key is changed in TCP MD5, segments using the old key would have been discarded (as having the wrong key). TCP-AO allows for key overlap. If there is evidence of resets being caused otherwise, a citation is needed.

The reason may not be resets and we can take that mention out. However, there is no well defined rekeying strategy either. Unless you count sitting on the phone, making calls to all other parties at the same time to change the keys. Operators will tell you that keys almost never get changed. If this was not true, it would not be mentioned in the KARP threats requirement document - section 4 item 7.

> 
> - Sec 2.3.1.2 suggests that TCP MD5 should be updated with SHA1
> This is incorrect; the appropriate recommendation is to shift to TCP-AO, which includes SHA1 already.

Accepted. Will update draft.

> 
> - Sec 4 discusses TCP's vulnerability to attack
> This would be an appropriate place to cite RFC 4953 as explaining the issues and problems.
> 
> The recommendations in RFC5961 are relevant ONLY where IPsec or TCP-AO protections are not used, and RFC5961 mechanisms do not protect against replay, spoofing, or other TCP attacks - only some RST attacks. This section should make it very clear that the use of these techniques does not replace the need for network or transport protection, nor are any of its mechanisms needed when such protections are deployed.
> 
> This section also talks about TCP-AO key rollover; the mechanism for rollover is defined in TCP-AO. What is missing is how the endpoints decide when to rollover and when to stop using an old key. That remains a key management issue.
> 
> Regarding connectionless resets, TCP-AO's Section 7.7 does address this issue in detail, and makes three requirements assertions to address that case.

Storing of keys does not help even if that could be managed securely. One needs ISN also.

> 
> The discussion of key rollover impact here is inappropriate; TCP-AO already handles that case without resets - or even packet loss.
> 
> - Security considerations
> This section makes recommendations that TCP-AO already covers (e.g., key rollover without connection loss -- or even congestion window impact, as well as replay protection). That should be noted.
> 
> ----
> 
> 
> 
> -
> 
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

Mahesh Jethanandani
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 1 May 2012 18:16:36 -0400

>>  i.e., that they would generate a reset, but this is not the case for TCP-AO,
   >>  nor was it for TCP MD5. When a key is changed in TCP MD5, segments
   >>  using the old key would have been discarded (as having the wrong key). TCP-AO
   >>  allows for key overlap. If there is evidence of resets being caused otherwise, a citation is needed.

 >  The reason may not be resets and we can take that mention out. However, there is no well defined rekeying strategy either.
 > Unless you count sitting on the phone, making calls to all other parties at the same time to change the keys.
[Uma]: With KMP support this is any way not the case. For the case you are talking about, i.e.,  manual keying, with AO "same time" is not a requirement as overlap is allowed.

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 May 2012 15:49:43 -0700

Hi, Mahesh,

On 5/1/2012 8:46 AM, Mahesh Jethanandani wrote:
>> On 3/26/2012 9:15 AM, [email-masked]
>> <mailto:[email-masked]> wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the Keying and
>>> Authentication for Routing Protocols Working Group of the IETF.
>>>

The document name isn't a big issue, and not worth the trouble to change.

For the title, it is currently:

  Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design
                                  Guide

IMO, it should be something closer to:

Analysis of Routing Protocol Communication Security Issues according to 
the KARP Design Guide

or

Analysis of Routing Transport Protocol Security Issues According to the
KARP Design Guide

(I think the second one is the most accurate, based on the document 
contents)

...
>> i.e., that they would generate a reset, but this is not the case for
>> TCP-AO, nor was it for TCP MD5. When a key is changed in TCP MD5,
>> segments using the old key would have been discarded (as having the
>> wrong key). TCP-AO allows for key overlap. If there is evidence of
>> resets being caused otherwise, a citation is needed.
>
> The reason may not be resets and we can take that mention out. However,
> there is no well defined rekeying strategy either. Unless you count
> sitting on the phone, making calls to all other parties at the same time
> to change the keys.

That sort of tight synchronization isn't required for TCP-AO. You can 
simply add the new keys to each side as convenient, and as soon as 
they're both available they'll be used.

The rekeying strategy isn't part of TCP-AO as a result.

 > Operators will tell you that keys almost never get
> changed.

There are two reasons:

1) the difficulty in deploying new keys, because of coordination 
required (which TCP-AO avoids)

2) the work of actually deploying the keys
For TCP MD5, this assumed manual key exchange which is cumbersome.

TCP-AO was designed to make it easier to support automated key exchange, 
but that key exchange protocol is not specific to TCP-AO. One is under 
development in KARP, though.

I.e., the whole point of TCP-AO was to avoid TCP MD5's disincentives for 
rekeying.

> If this was not true, it would not be mentioned in the KARP
> threats requirement document - section 4 item 7.

It is currently true, based on the current use of TCP MD5, but it might 
be useful to not discount TCP-AO on TCP MD5's grounds.

...
>> The recommendations in RFC5961 are relevant ONLY where IPsec or TCP-AO
>> protections are not used, and RFC5961 mechanisms do not protect
>> against replay, spoofing, or other TCP attacks - only some RST
>> attacks. This section should make it very clear that the use of these
>> techniques does not replace the need for network or transport
>> protection, nor are any of its mechanisms needed when such protections
>> are deployed.
>>
>> This section also talks about TCP-AO key rollover; the mechanism for
>> rollover is defined in TCP-AO. What is missing is how the endpoints
>> decide when to rollover and when to stop using an old key. That
>> remains a key management issue.
>>
>> Regarding connectionless resets, TCP-AO's Section 7.7 does address
>> this issue in detail, and makes three requirements assertions to
>> address that case.
>

The traffic key already incorporates the ISN information, as per Figs 7 
and 8 of TCP-AO.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 May 2012 14:34:54 -0400

I strongly prefer that the title include the names of the protocols
being analyzed.  I'm not sure I agree with Joe that it is desirable to
separate out transport/network layer issues from routing protocol
issues.  It's the system as a whole that we want to analyze and secure,
so I'd prefer the document set out to do that and succeed.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 May 2012 12:13:27 -0700

> so I'd prefer the document set out to do that and succeed.

That's fine, but that's not what the document currently represents.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 May 2012 15:27:07 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> On 5/8/2012 11:34 AM, Sam Hartman wrote:
    >> I strongly prefer that the title include the names of the
    >> protocols being analyzed.  I'm not sure I agree with Joe that it
    >> is desirable to separate out transport/network layer issues from
    >> routing protocol issues.  It's the system as a whole that we want
    >> to analyze and secure, so I'd prefer the document set out to do
    >> that and succeed.

    Joe> That's fine, but that's not what the document currently
    Joe> represents.

Understood. I tended to agree with your other comments and believe the
document needs some work.  I'd just like to get all the way to the sort
of analysis the design guide contemplates for routing protocols rather
than stopping at the transport issues.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 May 2012 12:30:30 -0700

On 5/8/2012 12:27 PM, Sam Hartman wrote:
>>>>>> "Joe" == Joe Touch<[email-masked]>  writes:
>

Sure - should that be in the same doc, though? I thought this doc was 
specific to securing the message exchanges, not the messages themselves.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 May 2012 15:58:51 -0400

>> 
    >> Understood. I tended to agree with your other comments and
    >> believe the document needs some work.  I'd just like to get all
    >> the way to the sort of analysis the design guide contemplates for
    >> routing protocols rather than stopping at the transport issues.

    Joe> Sure - should that be in the same doc, though? I thought this
    Joe> doc was specific to securing the message exchanges, not the
    Joe> messages themselves.

Ok, my assumption here is that there's fairly little to do beyond
securing the transport for these protocols. I do think the analysis
needs to be comprehensive enough to understand the protocol level
issues.  As an example, if TCP-AO didn't protect against resets, the
analysis would need to cover how a higher laye.r session resume feature
was used to avoid serious DOS issues or something like that.
However my assumption is that for the protocols in question that there
will be few such issues.

If that turns out not to be the case, then we should consider splitting
documents.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 May 2012 13:04:33 -0700

On 5/8/2012 12:58 PM, Sam Hartman wrote:
> securing the transport for these protocols.

Sure, but the devil - and most of this doc, AFAICT - is in the details 
of how to do that.

 > I do think the analysis

The current doc suggests there's more than enough for one doc on just 
those issues - which protocols to use, how to use them, etc.

> If that turns out not to be the case, then we should consider splitting

See above; I'm not sure there's much other than this in the current doc, 
IMO. That's the reason I wanted the title to reflect the contents.

Joe