[sidr] minutes from interim meeting

["Murphy, Sandra" <[e-mail]>]

We had two minutes takers from the interim meeting on 29 Sep.  They had different styles of taking minutes.  One set of minutes was more summarization: noting topics and outcome of the discussion.  One was more detailed: noting details of the discussion and who made what comment.

I myself find that both styles have benefit.  Luckily the two minutes are pretty synchronous with match points.  I have melded the two, so there is a topic and summary followed by the detailed discussion.  

I have checked against the recording when the minute taker was uncertain.  Aside from mis-spellings, anything I inserted is noted by <ed:    xxxx >.

The minutes are below and will be uploaded.  Corrections should be sent to the list.

--Sandy, speaking as co-chair







Interim meeting, 29 Sep 2012, Amsterdam, NL.

Link to recording of meeting: http://www.meetecho.com/ietf-interim/recordings


<Editor note: in the below, I believe that the names used indicate:
Matt: Matt Lepinski
Randy: Randy Bush
Chris: Chris Morrow
Rudiger: Ruediger Volk
Wilifred: Wilifred
Rob: Rob Austein
Steve: Steve Kent
Sandy: Sandy Murphy
Steffann: Sander Steffann
Sriram: Sriram Kitakalapudi
Eric: Eric Osterweil
Russ: Russ Housley


The meeting began with a discussion of draft-ietf-sdir-bgpsec-protocol-05.txt, with Matt Lepinski as presenter.

bgpsec-protocol-05 - Open Issues

Matt L: 5 reviews of the doc - discuss issues raised by those reviews
 -minor mistakes and improving of text he is fixing

1.	What to call the AS path that is protected in BGPSEC? Call it simply AS path. (That is distinct enough from BGP-4 AS_PATH.

Details of discussion:

 -We don't have an AS_Path attribute to reference in the docs, what do we call the sequences of ASes through which an update passes
 Randy: bgpsec path
 Matt: like to refer to those without referring to a set of attributes
 Chris/Randy: sequence of ASes through which an update passes is just fine

2.	Transport security: Suggested wording: If you wish to protect the transport, then you must use a form of transport layer security. (The document does not recommend specific one.)

Details of discussion:

Matt: Do we want to specify a mechanism for transport security? eg tcp-ao  -- if we don't specify there are residual things that bgpsec can't secure
Does it make sense to do a SHOULD or MUST without specifing a specific mechanism.  
Randy:  If you wish to protect against these vulns, then you must/should
Chris: No one does AO and MD5 is somehow bad, so Randy's right - 
No objections

3.	<ed: new topic re: Editor's notes>

Matt: Planning to remove Editor's notes in next ver

4.	Failure to negotiate BGPSEC successfully with a neighbor should result in falling back to negotiating BGP-4.

Details of discussion:

Matt: Negotiation errors - RFC5492 says if you fail to negotiate a capability you might send a bgp notification message and close the session.  
If I want bgpsec and my neighbor doesn't we fall back to regular bgp4 - my proposal is to reccomend falling back to bgp4 and not close the session
Would like feedback if anyone would prefer to fail the session: 
Chris: it sounds like an implementation choice - ask for a knob from vendor - you don't want a situation where you can't have a bgpsec router talk to a non bgpsec router
Matt: recommend adding a sentence that says fallback recommended, closing is fine
Rudiger: I think we need to know when the session comes up, which policy to push - whether bgpsec came up or regular bgp4
Randy: It's not bidirectional - you should know whether you can send or receive etc   Current doc does not document that you can be send only
Matt: I'll fix that

5.	Non-null SAFI: Matt will take it to the mailing list to see if anyone wants its inclusion. Rob: All rpki implementations are affected if you change the specification to include non-null SAFI.

Details of discussion:

Matt: SAFI - Do we need a safi present flag? 
Rob: The actual question is do we need a safi field at all? You are only allowed to use v4/v6 unicast with null safi. If we decide we want safi, 
then in order to express what's in 3779(?) we need a flag
Matt: is there is a use case for non-null safi in bgpsec ver0
Some guy <ed: the name is unclear in the recording and I do not recognize the voice>: Suppose I have non-complement ... from the same AS (mcast?)
Matt: This version does not handle mcast - you have to send without protection your mcast
Rudiger: The origin validation is only for unicast -- protecting the ASpath perse could be of value for people doing strange address families
Matt: Take to list - unless someone on list comes up with use case, then we will take it out

6.	4-byte ASN: Does negotiating bgpsec mean negotiating 4-byte asn also. No, you may negotiate 4-byte asn but not bgpsec. So have separate negotiations for the two capabilities.

Details of discussion:

Matt: Negotiation of 4byte AS
You need to support 4byte AS's - doesn't support 3byte hack
What happens when a speaker does not support 4byte AS? Do we close the session?
Some guy <ed: the name is unclear in the recording and I do not recognize the voice>: If I say bgpsec, and my neighbor says AS4 - then we do really want to negotiate AS4
Matt: seemed to get it

7.	BGPSEC capability negotiation: Have 2 separate messages, one for send and another for receive. Rob: Do 2unless you are short of capabilities. But don’t do subtyping, i.e. put one under another.

Details of discussion:

BGPsec has 2 options - I want to send you bgpsec and I'm willing to receive bgpsec
I may not want to do sig valid, but do want to generate sigs
I might trust my upstream to do this hard validation stuff and just generate my sigs
Is this an ok situation or a fail to negotiate
Randy: why don't we send 2 different capability messages, instead of 1 message with 2 bit flags for send/receive
Wilifred <ed: the name is unclear in the recording and I do not recognize the voice>: you should allow this situation
Matt: Currently you send 2 capability msgs (v4/v6) so now you would send <ed: two>
Heather: What is the harm of sending both
Rob: Don't add another one 
Matt: proposal is to keep it separate

8.	BGPSEC_PATH_SIGNATURES attribute name: Simplify to BGPSEC_PATH.

Details of discussion:

Name of the attribute: anyone have a prob renaming - No

9.	Router ID inclusion in the update: Final decision was not to include it in the BGPSEC update. Discussion: Steve Kent: SKI which is a hash of public key is extraordinarily likely to be unique. Router ID has significance between immediate neighbors; irrelevant two hops way. It is not relevant from a correctness point of view (in BGPSEC updates). Rob agrees with Steve. Consensus in the room for not including.

Details of discussion:

Router ID's
reccomends that routers have a subject name that includes a router-id identifying a router
do we add router-id as an unsiugned field right next to ski in bgpsec attr?
if we don't a large number od certs matching a given as must be sifted through
Does it make the validation code simpler/faster?
Rudiger: router id is a phrase that is used 
Sandy: you can put whatever you want in the router id field if you want to identify a set of routers
Steve: which fits in the field.  There is a subject name which is a character string  --- My argument is no we don't need it because the hash of the public key is likely to be unique to begin with
if at one end the knob says every router gets a different cert with a different pub k -- or different keys.  On either end there is no problem.  It's very likely to not be a big deal.  I think the 
likelyhood of collisions is small.  
Matt: current text suggests when you talk to cache you should filter by ASN then by ski.  Someone suggested that there was potentional of DoS attack if someone generates millions 
Steve: described ways to forge
Randy: problem occurs when you are in the middle.  (One key in America, one key in aspac) A router key is compromised in one region - idea is to restrict compromise to one continent, and you can't know unless the router id is in the update
Sriram: ...
Matt: Do I have information in my bgpsession that I can check my router id against so that I know which one the peer is using
Randy: It's not the peer, because it can be several hops away
Matt: if we put in routerid in the update msg, I can't check to make sure everyone in path was using the right router id 
Randy: If you glom that up you don't have that assurance
Matt: is that a useful assurance - is it useful to be able to check which key the peer is using 
Randy: I would use artificial routerids - in bgp they are only unique to an AS -- 
Chris: whether you are at the 1 key per router, or 1 key per AS, the peer only knows you signed a msg with a key, this is a troubleshooting and later validation issue
It's misleading to call this router id. Its an identifier for this key and everything that was signed by it.
Rob: from the cert side, I'm with steve
Steve: idea was when we open a connection between a pair of routers, immediate peer can check the guy who he thinks is configured, once you are more than 1 hop away this is irrelevant
you are checking for consistency to the AS, not to a specific router.  Immediate neighbor stops being interesting when you don't have a 1-to-1 
Matt: signing over routerid isn't useful if....
Steve: you don't have to have routerid in there - its not relevant more than 1 hop away.  Once you revoke a key, well you've killed the key and it can't be used anymore
Chris: thinking about this as routerid is a problem - think about it as random number that is 32 bits long
Randy: in the update that I outbound sign, my key in rpki is bound to that nonce, that allows me to protect a compromise on router A from compromise on router B
Matt: there is a compromised router and a good one.  the compromised router can use his comp'd key to sign on behalf of your AS, your concern is that if my comp in NA you don't want asia to be signing
<break>
Matt: what I have heard is that no one can provide a concrete security benefit for putting the router id in this doc - I will make this assertion on the mailing list - if anyone finds a usecase on the list, we'll sort it on the list

10.	Reserved field in the Update: Historically it is there because it was originally meant to be used for Expire Time (a method of replay protection). Its usability is good for protocol extension (expire time or other use) at the origin only. Jari Arko: You can add one TLV mechanism for one purpose using this. Randy: “If you design an extension carefully, it would have a 25% chance of designing for future. Since this was thought of for a specific purpose, it has much smaller chance.” Sriram: “I am neutral but we may like to wait a few months before removing it until the replay protection mechanism gets fully finalized. Periodic Key Rollover is something to be considered for its merits, and it is similar to Expire Time method. He said he and Doug wrote a document (announced it on the SIDR list on September 21) which discusses all the pros and cons in detail about different replay protection method.” Matt: Room seems to be leaning towards removing it; we will take it to the mailing list.

Details of discussion:

Additional info - is it useful?
add'l info - signed origin added blob of bits when we took out expire_time.  Some folks though we may in the future want to add expire_time or signing_time or something to support better protection against replay or other issues
Allows origin to assert something under sig, and allows us to support possible extension mechanism
is this still useful, is the current spec good enough
if we go from ver 0 to ver 1 we lose backward compatibility - 
Rob: I don't know if we need ext mechanism - I'm not convinced this is useful.  This is only good for originator only, as opposed to a long path.  This is taylor made for 1 ext we may never make. I won't stand in the way but not seeing a strong argument in favor
Guy w/ pink dot on badge (Jari? Jani?)<ed note: I believe that this is a reference to Jari Arkko>: It's useful that you can add exactly one TLE
Matt: I'm all for making this better if anyone has suggestions
Randy: be honest, this is restrictive extension mechanism not really designed as such - it's a vestigal organ, it's dead.  If you want an ext mechanism, design one
Rob: If you actually want an ext mech, look at the ipv4 header 
Matt: 2 things proposed - make it more general or kill it  -- Rob and Randy that says kill it. 
Chris: are we sure we never want to add anything more at the origin end.  
Randy: ...that's compatible with this
Matt: anything added needs to be able to be ignored by someone who doesn't understand this - so if its a security thing we don't want them to ignore
Sriram: not in favor or against - expire_time in origin made the update expire at a certain time- key rollover replaced this. Periodic key rollover mimics this.  If someone thinks expire_time is better because it doesn't create churn (key rollover has churn) so maybe
we keep it and see if someone is concerned about the churn. I'm neutral on this
Matt:  No other comments?  To the list.. the room is leaning toward kill it

11.	<Ed: new topic>

Non-bgpsec stuff in your AS

Details of discussion:

Matt: Attr is currently non-transitive - if you send to a speaker that doesn't understand, they drop it.  Will RR strip?
Rudiger: no
Randy: bgpsec ops doc says.. rr must have bgpsec enabled if/oif there are bgpsec speakers in their client cone
Matt: should this doc need to have a pointer to ops discussion of those considerations.  It was suggested that this might be a prob
Chris: monitoring comes up - If an rr doesn't accept bgpsec I wouldn't send them bgpsec data (wouldn't have negotiated) path constructed based on bgpsec and fwd'd
Matt: if I have a mixture of bgpsec and non-bgpsec speakers in my AS, is that a problem
Chris: 2 routers hear same prefix - one may choose it, one may not -- i might say, I trust my bgpsec speaking routers more than those that dont
Matt: I don't think there is a problem here - Sandy agree (you made the comment)
Sandy: Yes

12.	Length field: Rob: Traditionally the header in included in the length field; keep it that way. Decision: Length field value will include the overhead bytes used for the length field itself.

Details of discussion:

Does the value of length field inc octets used to express length field
Matt: I want to make them all the same 
Rob: 2 obvious right answers - historically these include the length of header, wrong decision 30 years ago, but we kept going with it -- not worth changing
Matt: I will go through and make sure this is consistent in the way rob suggested 9 (see slide) include length octets in length calculation

13.	Null BGP-4 AS_PATH or Null BGPSEC_PATH from originating router to egress router: Randy : “If originating router is BGP-4, then it will send Null BGP-4 AS_PATH. If it is BGPSEC and knows the egress is BGPSEC, it will send Null BGPSEC_PATH.” Question (note taker): How does the originating router know if the egress router does BGPSEC or BGP-4 only?

Details of discussion:

Originating an update:
Matt: Inside my AS a router originates a prefix, currently it creates an empty AS path, when it hits the edge it creates a aspath --- When bgpsec speakers are talkign to each other
using signed update msg.  ..... do I want my bgpsec speaker in the middle talking to the edge producing an unsigned msg ... reasonable approach: inside my AS I send empty aspath until it gets to the edge where it gets added
Randy: I know who I'm talking to 
Chris: Are you sure you are getting the update from them?  Isn't the genesis the discussion I should be able to know that my AS originated the route. 
Matt: seems silly to sign to yourself
Chris: proxying Danny's question
Sriram: does the msg received by the edge router, is it different if empty bgpsec path
Matt: semantics aren't different, bits on the wire are diff
Sandy: in one case aspath length = 0 and in other case you have bgpsec path =0
Randy: gives example - 
Sandy: what does something send the edge
Randy: if I am originating and speaking to 
if a null aspath reaches the edge and the edge speaks bgpsec, it becomes bgpsec
Rudiger: as long as the optional field is not around
Randy: no it will be done by the edge
Rudiger: in case you are actually putting the time in, if some unknown ext is put there it might make a difference
Matt: I'll take all to the list. the sense of the room is leaning toward empty bgpsec attrib

14.	Valid-Invalid vs. Good-Not Good: The room leaned towards Valid and Not Valid. Randy: “Someone on the SIDR list suggested a not unreasonable third state for bgpsec validation.

Details of discussion:

Validation state names
Matt: I would like to call the states valid and invalid.  Any probs with that?
Randy: Is it verifiably invalid, or couldn't validate
Matt: Couldn't validate is long
Randy: sure, not validated
Sandy: if the origin validation comes up with unknown or invalid, bgpsec comes up as not good.  If you translate not good to invalid.  I think you need separate terms so you aren't overloading
Rob: Valid and not valid works for me --- invalid means something different in this space
Matt: I will change to Valid and not Valid    
Rob: you may actually need to explain binaries (kidding)
Sandy: someone will ask origin has 3 states, this has 2, what happened?
Matt: I could, but doc is already long
Randy: that msg suggested symantics for the 3rd state in bgpsec validation that wasn't unreasonable 
Matt: we can do it there is a good use case

15.	Error Handling: General consensus was not to drop the bgpsec session if the parsing failed (i.e. syntax errors). There was difference of opinion whether the prefix should be treated as withdrawn or ignore the update (i.e. simply consider it never occurred). Sriram: If bit flipped in the NLRI, you would be withdrawing the wrong prefix. Ruediger: That is alright. Rob: Yes, the protocol document has normative dependency on the error handling draft in IDR.

Details of discussion:

Error Handling
Matt: current text log error and drop update -- maybe not the right text.  what can I reference for the right way to handle errors -- 4271 will tell us to close the session, which we probably don't want
Randy: draft-idr-handling - a little sarcastic
Chris: there are some errors you can handle because it doesn't affect routing, if bgpsec content is unparsable do I still accept the route or throw it away
Randy: you are going to have to classify in terms of that document
Jari: if you ever have to deal with both sec and non-sec info - if something fails you treat the info as insecure and up to policy on whether you accept it or not 
Chris: update is formatted properly but a bit gets flipped - in the bgp world you would notify and restart (bounce) - this is discussion idr is having - when does it matter and when does it not
Rudger: drop update or treat as withdrawl?
matt/randy: thats the prob
Rob: we dont constantly monitor logs - I saw nothing about mib counters in the idr doc - 
Sriram: problem is we have one bgpsec path which includes path info and signatures, if there is an error the whole thing is invalid. We dont have seperation.  there are only 3 choices, withdrawl, close session or drop update.  No option for saying
just a security error.  Is there a case for seperating path information in case there is an error and then you atleast still have the path for bgp4
Chris: if the bgpsec attrib is bad - if you believe they are half crazy.. you can't get the aspath and have to treat as a withdrawl.. then they are all crazy
Jari: if there is insecure data you don't want to override any secure data - 
Chris: I may choose to take the settlement free path over the secure path   If we fall back to the neighbor is crazy thats what we should worry about
Jen: I don't think we want to drop bgp -- I don't want to flap, but I don't trust the update, withdraw
Matt: inform the operator (not notify, not log..) 
Eric: how do you know?
Chris: you pack an update 
Randy: the flipped bit was in the nlri - treat as withdraw - this is going on in idr
Rudiger - hopefully they will come up with good language
Matt: 06 ver will say you should inform and treat as withdrawl
Sriram: you can't tell anything about the prefix so how can you treat as withdrawl?
Matt: in the early years it will be more likely that we stumbled into something untested rather than random bit flip via solar flare
Are you arguing to treat as if update occurred or shut session 
Sriram: as if it never happened
Eric: leave this to idr - hate to end up with 2 different results
Rudiger: if we get garbage from idr then we have problems - what kind of errors are we covering here - solar flare bit flips should have no impact
Chris: if you put transport security ON then you have to address it
Rudiger: we are looking at format errors in the bgpsec attribute, treat as withdraw
Rob: we do have a normative dependency on idr
Matt: suggest saying handle as you would any syntax error in bgp -- take it to the list

16.	Deferring Validation: Question: Router MUST or SHOULD validate later and reevaluate best path? The consensus seemed to be that router MUST reevaluate. Ruediger: Change in RIB entry will automatically trigger best path re-computation.

Details of discussion:

Deferring validation
Matt: I got multiple comments on this text: "During exception conditions (eg the BGPsec speaker receives.....).." suggestion that there should be text that says you may defer validation if you have to
more text that says "implementation that support such deferment of validation..."
Are these reasonable texts on deferring validation state?  Are these reasonable MUSTS?
To Rob - I got that you flagged a problem but am not sure what it should say.
Eric: I get the principle that you might need to do this, but this seems to open an attack vector - so we should describe the requirement to do this
Rob: must perform validation as soon as possible you could end up with a lot of side cases and reasons why it takes to long
Randy: the whole thing is a rat hole
Rob: operators wanted to be able to defer
Rudiger: we can deal with unvalidated stuff, the provision for dealing with that is a requirement for implementers - going into details is a rat hole, just stay out
Chris: The original reason was to maintain speed of convergence - if you back up and say we should just validate and run best path and move on - ops will ask vendors for a knob to defer and rerun.  You can unpack and get path info, 
then validate later. 
Matt: its the crypto that could be a problem later
Randy: I just got bgpsec updates and don't have a path to rpki
Rob: ask implementers.  add text that says, be aware you may want to rerun 
Rudiger: rerun policy and that implies rerunning best path
Sriram: have we made it clear somewhere that we have to check syntax error first.  
Matt: if your length fields are wrong in your tlv's then you arne't going to parse this
Matt: we really need to get implementers opinion on this and what you would like it to be 
Heather: don't see what is wrong with the text
Sriram: if you have path info and signatures seperate - if you decide to defer validation and it is simple to pick path validation 
Rob: lets not reopen that issue again
Rudiger: I think it irrelevent - i feel the language is bad, when we take a deferred object we run policy and insert result in rib which triggers best path -- wehn we do validation we have to rerun policy, this may change rib entry, which triggers best path

17.	Validation at Edge Only: Sandy: How does the text relate to RR. Matt: RR should not need to do crypto validation. Chris: “You can do crypto everywhere; you need no do crypto everywhere. Randy: “There are no bits in iBGP to convey validation state. Operator has to devise a way.” Heather: “That’s covered if you combine the two sentences in the middle on Matt’s slide.”

Details of discussion:

Matt: Edge Validation (see slide for text)
"Bgpsec validation needs only be performed at ebgp edge...." we really needed to say something about how you only need to validate at the edge.  This text might say to much?  Do I need to say the first sentence? Can I yank the entire paragraph.
There were multiple people who read this, who didn't like the message.  
Sandy: how does this relate to route reflectors
Matt: no one has suggested that rr's can't - no one is trying to take anything away
Randy: objected to "may be conveyed via ibgp" so give a hint that its conveyed by some mechanism  --it's a nit on the language 
Matt: Combine the middle 2 sentences -- conveyed via some mechanism 

18.	Choosing Valid over Unsigned: Randy suggested leaving that to the bgpsec-ops document.

Details of discussion:

Use of Validation state
Matt: Do we want to mandate that you cannot pick a non-bgpsec best path if you have bgpsec valid.  (everyone agrees?)
Do we want some text that says SHOULD
Randy: its in the ops doc
Matt: remove 1-2 sentences and leave it to the ops doc

19.	Re-run Validation: Upon receipt of RPKI state update, router will re-run those bgpsec updates that the RPKI updates may affect. Sandy: 4271 mandated re-evaluations if there are any. Rob: Careful about using the word “immediately”. Matt: References to rpki-rtr doc are informative.

Details of discussion:

ReRunning validation
Matt: RPKI state might change, do we need text that says to rerun validation algorithm
Randy: you will receive the withdrawal.  periodically is not the term that applies
Chris: I have a whole rib built and I go out and revalidate and the rpki cache does not have an entry for something that I had before.  Now Ive gone to not found and start sending updates
Matt: when I get a msg from rpki router saying there are certain keys that are no longer good, I look through rib and see if I am using ski's - you are moving from valid to not valid, so you don't want to treat it as a withdrawl
Randy: we are quibbling about when --- periodic or when you get the update
Chris: what if rpki update is no data?
Randy: Then it all gets marked not-valid
Chris: For all the changes I would go see how they affect me.  Check at batch of updates?
Sandy: Concentrating on rpki <ed: rpki-rtr> protocol, -- others not running it would notice a change
Matt: currently we don't have a normative reference on rpki router
Randy: the interesting case is the router itself being a validating cache
Matt: no one has a problem with everytime I learn of update I immediately revaluate those announcements which the update may affect
Sandy: rfc4271 language which tell you to rerun best path algorithm can't recall whats mandated there.  If they say you must do it, then its okay for us to say it.  If they have ifier language then we probably shouldn't have stronger language
Rob: "at earliest convenience" vs "immediately"

20.	<ed: new topic – getting keys to the router>

RPKI-rtr-keys

Details of discussion:

Matt: include informative reference to ymbk-rpki-rtr-keys  or says rtr or similar to?
Sandy: origin is mandated so we don't have to wait, it already applies as it currently exists - any future decisions don't impact <ed: origin validation is required for bgpsec, rpki-rtr is already useful for origin validation and should be mentioned for that purpose, whether or not it is eventually used for getting needed router keys>

Matt: That's it.. to the list

21.	Confederations: Randy: Confederation has to have its own trust anchor. Matt: “Someone from outside confed signs to the public ASN. The first AS of the confed does not have a technical problem with that; it is configured to know that the public ASN is. The second AS in the confed sequence along the update path should know it is an acceptable mismatch.

Details of discussion:

Randy: New Item - I am an incoming edge of a confed - I am not the canonic as of the confed - I am going to pass the received prefix internally observe that the confed will have to have a local trust anchor and its own data for the ases in the confed
on the left I'm as2, ont he right I'm as65000  I sign forward with as65000 to another confed member who goes to validate, they find the announcement to me is as 2
Matt: .....
Randy: you will allow the mismatched AS?
Matt: there needs to be an exception where the confed flag is set, the first person needs to permit a mismatch.  If I'm in your AS I know what the public AS is for the whole confed.  I'll reread it to make sure it's actually clear  The receiver should have
everything to verify the mismatch


<Lunch Break>

22.	Not obsoleting RF 4271. If you do not negotiate bgpsec with neighbor, behave exactly as a 4271 router.  

23.	Comparison with IDR WG: Sandy: Conformance with IDR-like requirement that there must be a working implementation before publishing as an RFC.  If you know implementers of bgpsec, please tell them that they let themselves be known to the SIDR WG.

Details of discussion:

Sandy: Comments on IDR stuff the relationship of this draft to 4271 we're adding on a new feature to bgp but also doing something about aspath those ppl taking an existing implementation and adding bgpsec attr need guidance on what to do in code
where code refers to aspath.  It's obsoleting 4271, there has to be some language that is good enough that tells implementers what to do when dealing with.. when the implementation refers to the aspath.  suggesting something like references to aspath
are to be understood that the aspath is extracted from bgpsec attr.   If you do not negotiate bgpsec w/ neighbor you should behave as current
Rudiger: appears to me designing compatibility with existing thing.  One should assume that for reg bgp processing one assumes out of bgpsec path, aspath info needs to be extracted and handled - which is a little different wording where we haev said "when
we are talking to someone else who doesn't know the new attribute or symantics - atleast have to virtually do the extraction and may have to be done physically." 
Sandy: Do we want mandate that they do it or not
Rudiger: we don't want to specific detailed implementation - treat as though you had
Matt: agreeing with Rudiger -- your implementation should behave as though you ran the extraction algorithm 
Sandy: where aspath modified I think those are cases where you would be adding a bgpsec signature block (missed first part)  If you do not negotiate bgpsec with a neighbor operate in accordance with 4271 --- Does that need to be said or is it understood?
Matt: I understand that whenever you fail to negotiate you fail back to 4271

Sandy: IDR operates under rules stricter than other areas - they require implementations in order to advance a draft.  We <ed: idr> haven't been faithful to that, but in this case we think they will be. So if you know of people doing implementations please make 
sure they make themselves known.  Not sure what the IDR chairs will accept as evidence -

Sandy: anything more about confeds
Room: crickets

Sandy: anything more about bgpsec protocol
Room: crickets

Sriram: is there a dependency of bgpsec doc on key rollover doc? 
Sandy: staleness and freshness - protocol draft does not rely on key rollover draft - any other opinions.. none ok

24.	Router-ID in communication of router key to router: The consensus was to not include the router ID in the rpki-rtr-key pdu.
25.	 Should Router-ID also be removed from the router cert data: Rob: Probably. Steve Kent: If helpful in debugging cert data, it may worth keeping it (cost seems small).

Details of discussion:

Randy: From this am -- pdu to transport router info from pki to router should not have router id in it, 
Chris: signed you mean?
Randy: rpki router pdu to carry the ecdsa public keys that will be handled by sig validation since this am we said they are not per router and router id has no meaning therefor do not transmit router in the pdu - looking for validation of that
Matt: I don't know whether I agree/dis I don't think that is outcome of this am discussion.  No security reason to put router id on the wire -- different from is it useful for some other reason
Randy: why push if you won't use it
Sandy: some suggested router id is useful in monitoring, debugging
Randy: anyone want to speak for keeping routerid in transport
Steve: When we regionally did cert design for routers, there was the notion that if you did different cert and key per router and were neighbor of bgpsec router and received signed update from it - you could check to see if sig applied by entity
you thought you were talking to on the other side.  Some say they wouldn't do it - still open question if you want that facility -- 
Sandy: do you need it for transport protection
Steve: forget bgpsec - if I configure info about neighbors, then we would have the ability to do this in a secure fashion - with this -- go from secure to a more secure.  
Randy: routers don't do this today - routerid comes in the open msg today.  Does anyone still want it there today
Rob: I don't know.  it could be useful for debugging in the certificate -- we have gone to lengths to make this difficult to debug by not having personal info it. I hope routerid is not considered personal info.  I like steve's idea of putting in
the serial field of the RDN. 
Sandy: anything else? anything else protocol related from this am

26.	Linkages to other documents: Chris: Linkage with idr-error-handling for sure. What else? Rpki-rtr protocol?

Details of discussion:

Chris: the protocol doc perhaps can't go fwd w/o threats and reqs docs being finished 
Matt: potential linkage to subsequent pdu for rpki-rtr if that spec if later extended people will be able to find it
Sandy: I think linkage to that exists without extension(?) of pdu

27.	<ed: new topic, small comment on pre-lunch discussion>

Details of discussion:

Steve: 2nd rob's suggestion of avoiding putting meaningful names in certs.  There is some benefit to putting in some info about what kind of cert it is.  Spelling out router and the AS is worthwhile and should make it unique. Small cost.

28.	Number of ASNs per cert: Rob: One cert can contain multiple ASNs. Sandy: Do we want single ASN per cert (like in the ROA)? Rob: Operator has a choice to put one ASN in the cert if they prefer. Matt: Will replace “the asn in cert” with “an asn in cert” in the doc.

Details of discussion:

Sandy: question about discussion between rob and steve about EE certs having ..language.. checking ee cert asn matching attrib field 
Matt: Many to one mapping between AS and certs.  1 cert can contain many AS numbers - you need to match a ASN.  My mistake in the doc, I'll go back and fix it
Sandy: ..something about revoking and having single AS numbers..
Rob: as far as protocol leave it to operator - they can shoot themselves in the foot
Sandy: no protocol change for that needed

29.	AS-Migration: See Sandy’s detailed slides – she presented them at the meeting. She presented how bgpsec with pCount=0 technique can try to hide (i.e. not contribute to path length) as the operator wishes under various AS migration scenarios. The discussion that followed was as follows. Randy: Wes George’s I-D is Cisco specific. Juniper doesn’t have all this. Ruediger: “Even if there is org boundary, if there is agreement with your neighbor, then “accept pCount=0” can be negotiated for the migration.” Sandy: In slide #7, CE-1 needs to be configured to accept ASN 200 in the AS path. Sandy: Can the trick used for the confederation be reused here in some form? Matt: This is different. As soon as update leaves, all the inconsistency info is expunged. Here it is not that.” Matt: Are the stuff with local AS etc. well documented. Rob: No, it is a vendor hack.” Sandy: Is anything different needed in the protocol document? Stephen: “Don’t just focus on how Cisco implements the hack. Check with other vendors as well.” Ruediger: “One vendor may be liberal, another not so liberal.” Sandy: “They are all trying to eliminate the extra hop.” Russ Housley (on jabber): “Since pCount was invented for other reasons, this is useful to document.”

(summarizing minute taker:) Details of discussion:

The discussion that followed was as follows. 
Randy: Wes George’s I-D is Cisco specific. Juniper doesn’t have all this. 
Ruediger: “Even if there is org boundary, if there is agreement with your neighbor, then “accept pCount=0” can be negotiated for the migration.” 
Sandy: In slide #7, CE-1 needs to be configured to accept ASN 200 in the AS path. 
Sandy: Can the trick used for the confederation be reused here in some form? 
Matt: This is different. As soon as update leaves, all the inconsistency info is expunged. Here it is not that.” 
Matt: Are the stuff with local AS etc. well documented. 
Rob: No, it is a vendor hack.” 
Sandy: Is anything different needed in the protocol document? 
Stephen <ed: I believe this is Steffann>: “Don’t just focus on how Cisco implements the hack. Check with other vendors as well.” 
Ruediger: “One vendor may be liberal, another not so liberal.” 
Sandy: “They are all trying to eliminate the extra hop.” 
Russ Housley (on jabber): “Since pCount was invented for other reasons, this is useful to document.”

(detailed minute taker:) Details of discussion:

Sandy - on to discussion of AS aliasing, migration
Sandy: (see slides)
Provider changes AS - customers aren't so quick to update
opt 1) Local_AS  CE-1 doesn't needs to be upgraded but AS300 gets inserted into AS_Path -- you now have an extra as in the aspath
Do away with side effect by doing no-prepend  so then the old-origin drops off
opt2) Local_as + no prepend gives the effect that ce-1 doesn't have to upgrade and 300 is inserted int as_path toward ce-1
opt3) Local_as + no prepend + replace-AS  

Notation sig(originprefix, target, as of signer, pcount)key
adds 2 signatures as if there were 2 peers inside the router -- 
In this case the recipient is inside the provider edge - there is no problem with the authority, the as that is accepting pcount=0 is under the same authority as the other AS (since they are on the same router) 

Sandy describes/reads slides 
...missed something..
Rudiger: plausible to say we are starting migration, we will be faking for a bit, if you are rigidly checking pcount 0 - then expect pcount 0 for migration
Sandy: this case came from 1st draft - things outbound from pe1 is sending things to the customer with new ASN 
Randy: its going to puke on open
Sandy: no pe1 and ce1 are using as300 for open  Will you check the first AS.  Default is supposed to be do the check, and that ce1 has to be configured to do this.
Randy: neighbor as is checked in the open not the path
Some guy <ed: from the recording, I believe this is Sander Steffann>: I think its checked in the path by default 
Rudiger: its different between vendors - some are liberal and some are strict.  All migrations I came across, faking the AS was always used where the aspath issued and the neighbor AS were consistent, which is not the case here
Sandy: when randy talked about the confed case where you are taking with your public as externally and your internal as internally
Matt: here is the difference in confed -- in the confed case the only people who see the inconsistency are within the confed and when you leave the confed the inconsistency gets expunged.  
Sandy: is this technique useful to employ in the confed case
Matt: no reason to add this complexity to confeds
Sandy: Wes was going to try to work out how as aliasing impacts- came up with other useful stuff, but not how pcount=0 might be useful
Matt: are local_as and replace_as well documented?
Rob: vendor hack
Matt: big question I'd like answered - the tools in the protocol doc are they sufficient to make this migration work or do we need to add some other lever to make this work
Sandy: I was not supposing there would be any different protocol behaviour to occur that isn't in the protocol doc
Matt: text going into 06 that says you really ought to check for pcount=0 and drop it if you aren't expecting it

Russ: since we adopted pcount =0 for other reasons this is useful
Sandy: this was not viewed as a change to the protocol
Randy: let Wes continue to document

Randy: Asked a question about delivering SKI
Sandy: let suppose someone takes of rpki cache and starts sending out ski's that match different keys
Rob: stop there you're toast.  Offload ..Chris messed with the screen couldn't hear.. 
why are you giving me both and making me think about this.
don't check for an error condition you don't know how to handle
Matt: cache is just offloading processing, it mgiht as well handle ski.  You absolutely need the key for sig ver. Do you offload the ski calculation to the other box or do it on your router?  Just ship it over and save me from doing
a few hashes
Sandy: does your answer change if we haven't protected router to cache transport
Rob: agrees with matt

Sandy: any other items?
room: crickets

Meeting adjourned