Routing Protocol Security Requirements WG (rpsec) Tuesday, July 24 at 1850-1950 State Ballroom ============================================ CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing and Administrivia BGP Security Requirements draft-ietf-rpsec-bgpsecrec-08 T. Tauber BGP Session Security draft-behringer-bgp-session-sec-req-01 M. Behringer OSPFv3 Automated Group Keying Requirements draft-liu-ospfv3-automated-keying-req-01.txt Y. Liu [ Meeting convened at 1853. ] Notes 0. No changes to the Agenda WG Co-Chair Russ White was not able to attend this IETF meeting. 1. BGP Security Requirements [slides] Presentation: http://www3.ietf.org/proceedings/07jul/slides/rpsec-0.ppt Tony noted that the SIDR WG is posed to work on consensus items as provided by RPSEC. Originating AS Authorization appears to have WG consensus. Transport Layer Protection is also ok Noted that section 4.2 (Incremental Deployment) of the draft there is a "MUST" regarding useful non-contiguous deployment. Should it be a MAY that information be propagated opaquely. Or SHOULD? Or a MUST? Is this burdensome to legacy ASs? RFC4271, sec9, para 2 describes treatment here. Do users want unclear validity data, or is it open to misinterpretation? Section 7 refers to the "special Note" in the text about the lack of consensus on a number of items. It was proposed to change this text to note a requirement to revisit this in the future. comments on section 7: Geoff Huston commented that the original version was unhelpful Sandy Murphy noted that she was happy to have this as a revision. Noted that there is still a MUST and a SHOULD is still confusing, and proposes to leave the text without the MUST and SHOULD Dave Ward commented that the document cannot progress without consensus, and if the document states that there is no consensus than this is contradictory. Suggest to change the normative text to a wording of "may in the future" Comments on section 4.2: Dave Ward commented on traversing legacy systems noted we have existing technology that uses optional transitive information in 4 byte AS support, so the question of whether it could work is demonstrated to work in the 4 Byte context. Sandy Murphy pointed out that the the MAY SHOULD or MUST does not refer to any specific mechanism. Dave Ward noted that RFC4271 noted that there was normative language there about this, and this could be used in the context of this document by reference. John Scudder agreed with the end statement that BGP RFC is fine here. The propagation can allow the side that understands the propagation can filter it. John noted that the alternative text with respect to the special note was a way to go forward. With respect to propagation question: Geoff Huston noted that there are two types of propagated information: incrementally altered and unaltered. In the case of unaltered information partial propagation is fine, but the incremental information is less clear. John - just ignore is fine Michael Behringer - ignore ie basically fine, but its more complex Sandy - one case is more complex it it passes and the other is more complex if it does not - it is really up to the nature of the information itself and yes or no a priori is hard so MUST is too strong and MUST NOT is too strong. MAY or SHOULD is probably reaonsable as a general position. Geoff Huston - with these document revisions, does this get us to the point of a WGLC? Tony: Yes, I think so, but I'll consult with my co-chair. 2. BGP Session Security Requirements [slides] Presentation: http://www3.ietf.org/proceedings/07jul/slides/rpsec-1.ppt Joe Touch refered to a Bellovin document that was relevant to session security and questioned whether there was a need for two documents on this topic. Michael Behringer noted that he referenced the Bellovin document in this RPSEC draft, but would recheck this. Joe Touch noted requirements to limit TCP header space, and processing overhead of packets on the outbound and inbound path in the other draft. Joe Touch: BGP currently is inherently dependent on TCP for notification of peer 'liveness' and its important to note that the RFC that describes the reset attack is coming out as RFC 4953 notes that there is a need for protection of incoming spoofed segments at the TCP connection level as well as the BGP level. i.e. this Transport Area document does cover this in some detail Micheal noted that the various protection mechanisms exist at various levels in the protocol stack, and that this document will be referenced. Joe Touch: What did we miss in the Transport area? Maybe you should check that we have referenced all these documents, and the Bellovin document (draft-bellovin-tcpsec) Michael will check that this work approrpiate references the transport area work. Sandy Murphy noted that the section on avaibility and restricting IP appeared to be solutions rather than requirements, and the requirement is about something other than solutions (Joe Touch volunteered to offer text) Michael noted that the document should also state that these sort of things (such as fragements) "must be handled" Joe notes that the requirement is "an efficient way of dropping non-session packets". This is actually general advice about sessions and operational issues to avoid session attacks Michael noted that the whole point of the draft was to head away from a single defence mechanism to look at a broader spectrum of requirements Joe Touch noted that the work in Transport for transport protections was intended to be generic in the sense that this was intended to protect applications that include BGP. Michael noted that the point of the draft was to capture the difference facets of BGP. Joe suggest that as a requirement for a protocol the Transport activity is in this space already and a BCP on when and why to use different mechanisms as advice to BGP deployers Michael: Then the TO DO list item was bogus in the first place? The value of the document was to go beyond single mechanisms and look at this at a broad set of requirements, but if the transport area is already working here...? Itojun: why is IPSEC not specifically mentioned in other areas? Michael: requirements rather than solutions is the point here Michael will review the Bellovin draft and judge the extent of overlap Sandy Murphy noted that there was not much overlap as the emphasis of requirements was quite distinct here - TCP and BGP centric approaches are distinct here. Joe: whats the issue here? If you want to protect the data then there are choices in one dimension, but if you want to protect TCP as well as data then this is different. There is overlap in the areas of protection of the data layer, but there are issues of identity in BGP here that are not part of the TCP document. I'm not referring to the entire document, but more the specific areas of the data layer. 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. Michael: this document is about solutions and cases, not requirements and mechanisms. Illijtsch van Beijnum: physical security is a relevant consideration here. Sandy Murphy: operational concerns about security for BGP also refers to Pekka Savola's draft about protecting network backbones was well received in the various working groups where it was presented, but current status of this document is unknown. This is nothing to do with this draft Followup Actions: - check this draft for extent of overlap with Bellovin document - then poll the WG regarding adoption of this draft as a WG document 3. OSPFv3 Automated Group Keying Requirements [slides] Presentation: http://www3.ietf.org/proceedings/07jul/slides/rpsec-2.ppt Bill Atwood: PIM work going on in parallel along these lines. Don't have bootstrapping problem. Requirements are same contrasting that PIM leverages unicast reachability. MSEC isn't meeting this time. Work will be run through MSEC and OSPF with RPSEC providing commentary as needed since protocol work doesn't get done in RPSEC. [ Meeting adjourned at ~2000. ]