Minutes for SIDR at interim-2014-sidr-1
minutes-interim-2014-sidr-1-1

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.