Subject: Re: [RPSEC] Last Call for draft-ietf-rpsec-bgpsecrec-09

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Mar 2008 16:53:53 -0400

As usual, I'm catching up on drafts at IETF.

On Tue, Feb 26, 2008 at 08:31:47AM -0500, Russ White wrote:
> I'd like to start the two week last call window for
> draft-ietf-rpsec-bgpsecrec-09. There haven't been any changes for a long
> time on this one, and Tony's done an excellent job of pulling all the
> various comments together, etc.
> 
> Please send in any final comments before March 14th (slightly over two
> weeks).

IMO,

Stick a fork in it - it's done. 

-- Jeff
_______________________________________________
RPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rpsec

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2008 04:37:36 -0700

Russ White wrote:
> Y'all:
> draft-ietf-rpsec-bgpsecrec-09. 

IMO, the document needs to be more clear about the layers at which 
security is being described. The abstract makes a specific assertion 
about scope (direct manipulation of BGP and information contained 
within), but the doc repeatedly exceeds that scope by discussing issues 
of TCP integrity. The ONLY exception to this is the kind of "binding" 
issue of taking advantage of associations in IPsec or TCP/MD5 (and its 
potential successors) in pinning BGP. Issues of network or transport 
layer protection are out of scope, and need to be removed.

Specific suggestions:

Abstract - would benefit from explicitly stating whether this ifocuses 
net, transport, or routing layer requirements. It appears to focus on 
routing (as per the "Attacks that do not..." assertion), but this needs 
to be carried throughout the document.

Abstract - If "attacks that do not involve direct manipulation of BGP, 
and the information contained within BGP, are outside the scope of this 
document", then the mention of TCP issues are outside the scope of this 
document.

MUST/MAY/SHOULD - it's not clear that such terms should be used in an 
Informational document, IMO.

sec 3., first bullet on peer comm: I disagree that TCP integrity is 
relevant, if the assertion in the abstract about scope is accurate.

sec 11., the note about linked authentication is important - and should 
be carried down to the network layer potentially. However, this section 
should be retitled "linked protection layers"; it is not really about 
transport security. The sentence about transport security requirements 
('a detaileed treatment') should be moved to the intro, where the scope 
of the doc should be reinforced, and should include pointers to 
Bellovin's doc and TCP-Auth-Opt, IMO.

sec 12. since transport is out of scope, it's not clear why TCP-MD5 key 
management shortcomings are relevant; this first sentence can be omitted 
without loss of impact.