Minutes IETF98: sidrops
minutes-98-sidrops-00

1255: delayed start due to slide upload and A/V problems

1500 start of first sidr ops meeting

chair slides

sandy (notetaker) spoke about status of remaining drafts in SIDR

1507 Brian Wiess = router keying rollover
slide 2 - overview
critical that a router receive a (new) router certificate in time

slide 3
certificate only rollover events

slide 4
you have a new certificate and a new key pair
emergency rollovers a key (:-) ) concern

slide 5 steps in a rollover
five steps -
generate new key pair,
publish new certificate in global RPKI, receivers will get any new key to the
bgpsec routers, ues new key to sign

slide 6 how long is a rollover event

slide 7 when CRL is not required
don't need the twilight stage

slide 8 - cert only rollover
only need first two stages

slide 9 - ready for wglc
(reference to draft-ietf-sidr-rtr-keying - mentioned in sidr status as ready
for wglc) Chris: will ask one more time to the list if it is ready for wglc

15:15
Sriram - bgpsec-protocol draft and extended messages draft
slide 2
the IDR extended messaes draft is back in the IDR wg, but bgpsec-protocol has a
normative reference

slide 3 is extended messages really needed in bgpsec?
average over 5 million updates shows averages of AS_PATH that seem to indicate
the current bgpsec signatures with ECDSA P-256 alg don't really need extended
messages

slide 4
Alvaro strategy - change reference to extended message draft to a reference to
"maximum message size"

slide 5
new wording to follow this strategy

slide 6
what if sending Secure_Path_Segmetn and Signature Segment exceeds "maximum
message size" (a) convert to unsigned update (b) do not send the update

RV at mic: would not like the second option - you would need to send a
withdrawal.  Sees no problem with the first option

Jakob Hietz Cisco - could you have more than one NLRI in a bgp update?  Chris:
you can, but uncommon

Keyur Patel - need text to say what you do if you want to send an unsigned
update.  probably need to say follow the way to produce an unsinged AS_PATH

ROb Austein DRL: does this problem (overflow) ever occur in regular BGP

John Scudder: yes, implementations do have to handle this case.  would be good
to follwo that thought process

Wes George: try not to surprise people, make sure you highlight this.  Do not
loke this - yet another case where we are dropping back and failing open.  Can
we split things into two updates?

Chris/others: no, BGP does not support that

RV: a very rare case, requires more than 15 unique ASs in the AS_PATH.  WOuld
we think people by that time *NOT* have updated their routers to a version taht
woudl support extended messages.

Warren Kumari: a vulnerability for a attacker, to deliberately produce a
A-B-A-B path that exceeds the maximum messae size

Job Snijders NTT: My colleagues said 15 was unlikely, but Lacnic sees paths
that are easily 15

Chris says: slide said 15 was the average, would need 3 of those in order to
blow the maximum message size

Wes George: we do need to consider the Warren vulnerability

Randy Bush: the problem is that the extended messages is now have to cover all
update types - with IDR speed, that could take a while, even so bgpsec speed of
deployment is not going to beat it there.  put extended messages in the
informative and don't try to complicate the bgpsec protcool

Doug Montgomery:

John Scudder: yes, it would generate an error

Keyur Patel: extended messagse has met iDR criteria, should just proceed as is

John Scudder: there are several option, that is one, you would have to wait for
IDR to finish.  Is the wg concerned enough about publication to try to rush
this?  Randy's comment is Perfect is the Enemy of Good, just make the reference
move to informational and leave it at that.

Chris: discuss this on the mailing list - He will send msg today and set a two
week discussion time.

ALvaro: please discuss this in sidr
Chris: will send to both
ALvaro: does not go back to wg.  when we decide send text to wg(s) and IETF as
to decided new text, and if no one objects, I will approve and the RFC Editor
will publsh

Randy: not necesssary to say anything aobut the Update size - it follows rules
of BGP Updates.  Just need to move the reference.

Yossi Gilad substituting for Sharon Goldberg - The use of MaxLength in the RPKI

slide 2 - RPKI defezts prefix hijacks

slide 3 - but a loose maxlength in the ROA allows a forged origin subprefix
hijace to succeed

mentioned in RFC about rpki operations

slide 4 - maxlength misconfigurations are common -

slide 5 - recommends:
    don't use maxlength
    have lists of prefixes taht are originated
    use minimal ROAs where you authorize only originated prefixes

 slide 6 - wrote tool to take a set of RPKI ROAs with lists of prefixes back to
 maxlength version

 RV: I would say just don't sign ROAS for prefixes you don't want to advertise

 Sandy: there are two implementations of the CA function that warn an operator
 that a ROA was just about to invalidate current advertised routes. Nothing
 says that an operator who is trying to produce a ROA won't be as inclined to
 do the

 Randy: Tim Br of RIPE wrote the CA implementation for RIPE - and spend some
 tiee to

 Chris: there is a tradeoff between wanting to get the data out there and
 wanting the data to be carefullyu

 Rob Austeing: are you suggesting lots of ROAs or multiple prefixes in a single
 ROA.  A: the Second  ROb: a bad idea.  The ROA structure is all ASN focussed. 
 The operators seem to think this is not the right approach, because changing
 the AS to announce one prefix makes it necessary to change the ROAs for lots
 of other prefixes.  Telling people to pay attention to max-length is OK.

 RV: current RPKI database, just the first ROAs, looks very much like operators
 don't know what they are doign.  education and additional help in the UI is
 fine.  before max-length, there was a bit that said "allow all more specifics"
 a surprise to the implementers that NOT

 what i'm seeing in the database, a ROA for a /16 for an Asian ISP, and also a
 ROA for a /24 for the very same AS.  Looks like two different poeple did this.
  People need to take this seriously.

 Randy: many years ago, a fried, Geoff Huston, people were complaining about
 ipv6 prefixes going to Singapore to get to west coast US

 Job Snijders: max-length mpas directly into what people do with their prefix
 space - when they get a DDOS attack, they swing routing for one /24 to behind
 a DDOS protector.  they try to preseed the IRRs with route objects for all
 possible route objects or use max-length.  you correctly observer that people
 don't understand.

 Rnady: I need to produce ROA so when the scrubber announces the route, the
 route is valid.

 new topic

 BGP ROles and its applications

 Alexander Aximove, Randy Bush, Evgeniu Bogomazov, Keyur Patel

 be vary carefu in creating any new

 slies 2

 engineers prefer flexibility, leave no knobs untruned - but can have very
 expensive consequences

 slide 3
 consequences - number of prefixes (and number of prefixes leaked) in March

 slide 4, slide 5 - possible roles and peering relationshipo - need to be
 represented in BGP - in OPEN msg - would allow agreement between neighbors of
 their respective roles

 slide 6 - prevent leaks, detect leaks, detect deliberate leaks.

 slide 7 - must be in OPEN message, in order not to be circumvented by
 flexibility and knobs

 mic:

John Scudder: about "hardcoding in OPEN msg is curcial"  - what are you going
to do to OPEN msg. A: you must be sent to your neighbor JS: it is a capability?
 A: yes

next topic

overlap a bit to previous talk
about route leak prevention and detection

slide 2: description of route leaks
slide 3: intra-AS, use ibgp community/attribute/etc, inter-AS, use community
(or attribute) cofigure peering relationship per neighbor per prefix

slide 4: oob communication between neighbors

slide 5: using attribute for inter-AS solution with an optional transitive
attribute

slide 6: no single point of failure, attribute is set by each ISP, participants
can detect a leak whether the ISPs in between are participants or ot

slide 7: relationship between OOB communication of role/relationshiop and
previous BGP Roles in OPEN msgs approach.

Mic:
Sue Hares = we (she and Sriram) talked about an issue - about aggregates

Job Snijders: we in this room has an idea of customer and peer, but in real
world, some of our customers think we are a peer, some of our peers think they
are customers.  I think the ideas have merit, but think we need to consider
what the people who are using this will be able to understand.

Randy: I apologize for suggesting this - but you might think people would
actually read the documents.   Our draft defines the relationshiops.  Nothing
to do with business relationships, stated in terms of route propagation only.