Subject: [RPSEC] Notes from IETF69 WG session

From: Geoff Huston <[email-masked]>
Date: Wed, 25 Jul 2007 10:54:47 +1000

Routing Protocol Security Requirements WG (rpsec)

Tuesday, July 24 at 1850-1950 State Ballroom
============================================

CHAIRS: Russ White <[email-masked]>
         Tony Tauber <[email-masked]>

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

Notes

0. No changes to the Agenda

1. BGP Security Requirements

[slides]

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 WSGLC?

Tony: Yes, I think so, but I'll consult with my co-chair.

2. BGP Session Security Requirements

[slides]

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

Jo Touch noted requirements to limit TCP header space, and processing 
overhead of packets on the outbound and inbound path in the other draft.

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

Jo 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 (Jo Touch volunteered to offer text)

Micheal noted that the document should also state that these sort of 
things (such as fragements) "must be handled"

Jo 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

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

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

Jo: 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]

[note taker had to leave at this point...... Baton passed back to chair]

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

---

From: Tony Tauber <[email-masked]>
Date: Wed, 25 Jul 2007 14:06:41 -0700

Thanks, Geoff for taking notes. I merged in some others and posted them
at http://www3.ietf.org/proceedings/07jul/minutes/rpsec.txt.

Send any comments or corrections soon, please.

Cheers,

Tony