Subject: [RPSEC] draft-behringer-bgp-session-sec-req-02.txt

From: "Michael H. Behringer" <[email-masked]>
Date: Fri, 10 Aug 2007 10:10:53 +0200

Working group, chairs, 

Please find the updated version of the session security requirements draft at 
http://tools.ietf.org/html/draft-behringer-bgp-session-sec-req-02

I believe that this version addresses the concerns raised in Chicago, it clarifies the scope, plus it includes quite a lot of private feedback I have received. Below is the list of most important changes. 

Some people have already expressed their support to make this a WG doc at version -01, I believe that this version should now have sufficient consensus to make it a WG doc. 

Can we have a vote? 
Thanks,
Michael

Changes to the -01 version: 

- (sect 1) Added reference to I-D.bellovin-tcpsec; clarified scope.
- (sect 2) Added wire tapping as a threat into the threat model. 
- (sect 2) Added a reference to I-D.savola-rtgwg-backbone-attacks, since it puts the threat model into a wider context. 
- (sect 2) Removed in the "not considered threats" section general attacks against the router. Stephen Kent pointed out to me that if we do not limit ourselves 100% to the actual BGP session itself, then this must also be considered. 
- (sect 3.1) Clarified the requirement that a router may need several identities; text was confusing. 
- (sect 3.2) deleted the mention of "lightweight", since it caused more concerns than it seems to solve. Added to new section "general considerations". 
- (sect 3.3) Changed from SHOULD to MUST in "It MUST be possible to use various algorithms"
- (sect 3.4) Changed from SHOULD to MUST in "If confidentiality services are provided, they MUST allow for different crypto algorithms"
- (sect 3.6) reworded the paragraph on fragmentation completely. 
- (sect 3.6) added a reference to I-D.ietf-opsec-infrastructure-security as background why these things are important.
- (sect 3.6) changed the wording away from operational BCPs to a real requirement doc. 
- added a new section 3.9: "General considerations", where I try to address the questions of "light-weight" and "easy to configure". I hope I haven't made matters worse than they were before :-) This is a hard nut to crack...
- (sect 3.7) took out the definition of "easy to configure"  --> went into "general considerations".
- Lots of editorial changes (readability, references, etc)
	
Still to be addressed: 
- Illijtsch van Beijnum: wondering about key management issues for MD5 for BGP - whatever happened to this work? The issue is important in terms of keys, identity, storage, and similar. physical security is a relevant consideration here. 

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