Subject: [sidr] Fwd: minutes and updated slides uploaded

From: Sandra Murphy <[email-masked]>
Date: Wed, 5 Nov 2014 17:05:27 -0500

Looks like auto-complete in the recipient list meant that my message below went only to the sidr secretary.

Sorry about that.

--Sandy

Begin forwarded message:

> From: Sandra Murphy <[email-masked]>
> Subject: minutes and updated slides uploaded
> Date: November 4, 2014 9:00:48 PM EST
> To: SIDR Secretary <[email-masked]>, "[email-masked] wg" <[email-masked]>
> Cc: Sandra Murphy <[email-masked]>
> 
> I uploaded minutes, with thanks to Sue Hares for taking the minutes.
> 
> I made a few name spelling corrections.  I added a comment where Sue had recorded something I said that I did not recognize.  Anyone else who remembers that part of the conversation can clarify.
> 
> There was one participant who introduced himself as Chris from Australia.  Neither Sue nor I were certain of Chris's last name.  If anyone knows who that might have been (I thought the last name might have been Weiren), could you please let the chairs know?
> 
> I made a few changes to the slides as noted in the meeting.  I changed "Ie" to "I.e.," on slide 11 to help those who thought it read "le", as in "less than".  I added the router keying draft to the list of documents, noted as missing during the meeting.  I deleted two spare slides at the end - more colorful versions of previous slides.
> 
> The minutes are copied below.
> 
> If anyone has any comments or corrections, please do send them to the list.
> 
> --Sandy
> 
> 
> 
> Attendees
> 
> ·      Susan Hares
> ·      John Scudder
> ·      Chris Morrow
> ·      Sandy Murphy
> ·      Chris from Australia, last name possibly “Weiren”
> ·      William (Bill) Attwood
> ·      Mike Baer
> ·      Jeff Haas
> ·      Jay Borkenhagen
> ·      Alia Atlas
> ·      Doug Montgomery
> ·      Kotikalapudi Sriram
> ·      Oliver Borchert
> ·      Hyojeong Kim (RSVP'd but not certain was in attendance)
> ·      Kambiz Agahian
> 
> SIDR Meeting
> 
> 10:05 Recording attempted but failed.
> 
> Meeting intended to provide a little bit of background for the IDR folks who will be asked to comment on the SIDR draft. This background provides the necessary information for IDR participants to review the BGPSEC work.
> 
> Slide presentation
> 
> Questions after slide 10:
> 
> ·      John:  How large will these signatures be?
> ·      Sandy: One of the drafts (algorithms), these certificates use ECDSA. 
> ·      Doug: We could send a note regarding how the BGPSEC impacts the normal common RIB.  Size of signatures and how this could related to common RIBs
> ·      John: I’m asking how many bytes per ARC
> ·      Sriram: 64 bytes (P256 curve) per AS
> ·      John: This is contrasted to 4 per AS.
> 
> Slide 11:
> 
> ·      Sandy: We have done away with the AS Paths, and it is encoded in the BGPSEC Attributes. Including the AS Path might confuse.   We did not tunnel the ASPath information as the 4 Byte AS does. There is an algorithm to extract the valid ASPath from the BGP Sec AS Path.  An implementation can remove it from the BGP SecPath attribute upon reception. At the boundaries, you must strip the BGPSEC Attributes.
> 
> 
> 
> 
> 
> Slide 12:
> 
> ·      [Chris W(?)]:  Can you tell me how this will impact on global routing system on carrying the signatures?  
> ·      [Sandy]: Rephrasing the question if you send one NLRI per update, how does this expand the space requirement?  Secondly, how much does the signature add per ASpath. 
> ·      Doug M: The RIB modeling dealt with the signature size issues. We’ve presented these details  at a SIDR meeting.  
> ·      Sriram: We also looked at how many more updates how many more updates will you have.  When we examined this 4 years ago, there were an average 3.8 NLRI per attribute path. Therefore you will grow by 4 times.
> ·      Jeff:  In the grand scheme of input, I agree that the data flow of will grow by 4 times per update.  However, the major costs will be processing time and internal space sharing due to the lack of caching of the ASPath related attributes.
> ·      Sandy: Can you tell us why it is impossible to share the AS Path.
> ·      Jeff: Most attributes tend to share objects as shared objects  (AS, next-hop, etc). The problem is that the AS-Path will not be able to be shared.
> ·      Sandy: I see that the signature is not sharable.
> ·      Jeff:  In implementation, these tend to be grouped together.
> ·      Doug: If you are caching at the attribute level.  Then the path-attribute would be unique for each attribute that is signed.
> ·      Sandy: I do understand that the signatures are unique. If your code is caching attributes, this should not prevent as_path sharing?
> ·      Jeff: You need to store the signature as an attribute of the path attributes.
> ·      Sandy: It should not hamper
> ·      Jeff: Implementations may need to change our cache. The processing of the AS path is big part of the caching methodology. Therefore the caching will be higher than you consider in your estimates of per route estimates.
> ·      Sandy: Should we consider this input?
> ·      Jeff: The point is that this will impact the routes
> ·      John: People should think about what this means for their attribute list.
> 
> Second question stream:
> 
> ·      Sandy; Does this impact the route server functions?
> ·      John:  There are two document: Route serve ops draft is a grow draft – it is in or past IETF LC. The Route Server is an IDR draft, and it is not yet ready for WG LC.
> ·      Sandy: I was not certain if the route-server changes were in-spec or out-spec for BGP of the information.
> A Router-server operates as a collection point for routes at an exchange point (IXP) from all peers.  The route-server removes its own AS, and the path length does not change.
> ·      John: For BGPSec, the route server is visible as regarding signatures, but invisible regarding the path length.
> ·      Sandy: The route server sends ASPATH with a key encrypted.   (From Sandy: I am not sure what I said here.  The route server sends a BGPSEC attribute with itself included, but is flagged as a route server, so the ASPATH path length does not increase and the route server AS would not appear in the extracted ASPATH)
> ·      John:  People who care about Route Server scalability should review previous slides.
> 
> Slide 13:  No additional questions
> 
> Slide 14: 4 byte AS numbers are assumed.
> 
> Slide 18:
> 
> ·      Kambiz: Will BGPSEC change the decision process?
> ·      Sandy: The results of the BGPSEC process will be available for the decision process.  The BGPSEC process will mark whether this is valid or not.  This is then left to the BGP decision process.  These are similar to the BGP-origin state.   One example one operator adds +100 from preferences valid and subtracts 50 for the invalid state.  There has been discussion that under a heavy load you send all routes.
> ·      Kambiz: Can this be done on a private AS.?
> ·      Sandy: RPKI is for global and public resources. The certificates are all related via the trust hierarchy.  You can set-up a local RPKI to handle local address space (E.g. RFC1918 space) and then use BGPSEC path attributes. 
> ·      Sriram: We do have fairly detailed RIB-size modeling slide for normal routers and route-reflectors (Quebec Meeting).
> ·      Sandy: I think that your route-reflector mode would be similar to route-servers.
> ·      John: Sriram did you have the same information for CPU load – Would you include that?
> ·      Sriram: yes we do. We assumed general purpose processor (Sandy bridge, KVM process) on how the BGPSEC mode.
> ·      Sandy: Can you bring this up in the joint meeting.
> ·      Jay Borkenhagen:  on slide 18, partial deployment   two clouds of BGPSEC do not know of each other.  What happens if AS456 is partially deployed? I think that the only thing that matters is that there is a pathway through AS456 can be connected.
> ·      Sandy: This is an interesting point. I do not know how operators will deploy BGPSEC.  Do you think it will cause a problem?
> ·      Jeff: This feature will be partial islands of secured information.  You will have an AS will be half secure and half secure. It is likely that the security aspects of the BGP information will impact deployment. This may increase tunneling between ISPS.  This may impact forwarding.
> ·      Sandy: This forwarding can be done via tunnels or careful next-hop handling.
> ·      Sandy: I’m not sure what happens when one routing policy is not contiguous through an AS. 
> ·      Chris: Some of this operations process and some of this is implementation specific.   comments.
> 
> 
> 
> Final comments: John: We have an open agenda for BGPSEC.  Please send in agenda suggestions to both the IDR and the SIDR chairs.
> 
> Meeting ended at 11:25 am.
>