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

From: [email-masked]
Date: Mon, 26 Mar 2012 09:15:16 -0700

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01.txt

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Mar 2012 07:39:45 -0700

Comments attached below.

Joe

> http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01.txt

----

- the document name and title are misleading
- 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.

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

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

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.

----

-