Notepad for IETF 122

[BasilGuo]

• Discussion about FC-BGP in mail list: [Idr] FC-BGP practicality over BGPsec
• Jeffery's concerns:
  • [Idr] FC-BGP presentation at upcoming first session for IDR at IETF 122
  • slides-122-idr-sessa-08-2-jeffs-commentary-on-fc-bgp-attribute-00

Jeff: Thank you for the clarity in the document. (Open the slides for
the discussion points.)

Jeff: The state covered by FC attribute can be helpful for the
validation of portions of the path graph. ASPA just validates vally-free
routing, they are slightly different. Comparing with SoBGP, FC-BGP
provides directionality in the graph. BGP-iSec uses RPKI to detect
whether a signature should be present, may also be leveraged by FC-BGP.

Jeff：The question to be discussed in IDR is: does carrying cryptography
inside BGP update give us benefit? Personally consider it as one-time,
thus can be used for "copy and paste" replay attacks. BGPsec has a
similar issue, but the replay is harder.

Think FC-BGP has value as a policy element in RPKI. It also has some
value to reduce the attack surface. While there is a threshold in
incremental deployment to limit the copy & paste attack. Maybe we want
to get the path attributes signed?

Zhuotao Liu: Think the concerns are valid. May consider to have
something more static in RPKI as side evidence, but try to not add too
much dependency to RPKI. Think even with the copy & paste issue, FC-BGP
is still meaningful in providing security guarantee.

Jeff: Agree. Should continue the discussion on mailing list. Suggest the
WG to think about the difference between FC-BGP and BGPsec, whether
something that isn't a full chain of signature is what we want, and
decide whether the properties is enough to make operators, the
implementers and the whole internet happy. Please attend sidrops meeting
where the discussion will continue.