Subject: [Idr] draft-ietf-karp-routing-tcp-analysis review requested

From: Stewart Bryant <[email-masked]>
Date: Mon, 17 Dec 2012 18:29:55 +0000

Hi all,

draft-ietf-karp-routing-tcp-analysis is on the IESG agenda for 10/Jan. 
It has been through IETF LC, but we realize that it would be useful for 
the IDR, MPLS, PCE and PIM working groups to pay special attention  to 
the draft review the sections of this draft that are relevant to their 
(your) work.

I would appreciate feedback from anyone in the WG, but it would be
helpful if the WG Chairs could nominate at least one person to review
the draft on behalf of the WG.

Thanks

Stewart

---

From: Russ White <[email-masked]>
Date: Mon, 24 Dec 2012 08:03:31 -0500

> the draft on behalf of the WG.

Some thoughts below:

==
Those that use TCP as a transport protocol use access lists to accept
packets only from known sources. These access lists also help protect
edge routers from attacks originating outside the protected domain. In
addition, for edge routers running eBGP, TCP LISTEN is run only on
interfaces on which its peers have  been discovered or via which routing
sessions are expected (as specified in router configuration databases).

Not all routers actually do run access lists –but they may run access
lists for protection. This wording might need a little clarification,
perhaps: “Those that use TCP as a transport protocol may use access
lists to protect…”

The second part here, about TCP LISTEN, I didn’t really understand. Why
should TCP LISTEN be run on eBGP speakers where peers have already been
discovered? There is no discovery process in BGP, so I’m not certain
what this section is supposed to mean.

==
Generalized TTL Security Mechanism (GTSM) [RFC5082] describes a
generalized Time to Live (TTL) security mechanism to protect a…

I think this needs to be preceded with a “The.”

==
Even when BGP, LDP, PCEP and MSDP sessions use access lists, they are
vulnerable to spoofing and man in the middle attacks.

There’s something of a flow problem here… You begin talking about access
lists, then provide some short sentences on GTSM and TCP robustness,
then you continue here discussing cryptographic methods as if the
intervening paragraph didn’t exist. It’s a bit confusing –I would
suggest either generalizing the initial sentence here, or moving things
around so the two references to access list are in one place.

==
TCP MD5 does not provide a generic mechanism to support key roll-over.
The Message Authentication Codes (MACs) used by TCP MD5 option, is
considered too weak both because of the use of the hash function and
because of the way the secret key used by TCP MD5 is managed.

This section seems a little rough… There is the mention of the lack of
support for key rollover –which I take to be related to the management
of the secret key, but the two don’t appear to be connected in the text.
The second problem, the weakness of the hash function, isn’t well
explained, nor supported by outside references. Some beefing up here
might be useful.

==
It is well known that the longer the same key is used, the greater the
chance that it can be guessed or exposed e.g. when an administrator with
knowledge of the keys leaves the company.

Another threat that could be mentioned here is the longer a key is used,
the more material and time an attacker has to break that key through
computational means.
==

HTH

Russ

-- 
<><
[email-masked]
[email-masked]