IETF 120 PANRG Minutes

Chairs slides & Notewell

SCION draft updates (Nicola Rustignoli)

Talk

• Brief updates on 3 core SCION specification drafts
• In IETF 118, presentations from early adopters ==> Where does SCION
  work fit? ISE ==> Core spec PANRG ==> Actual deployment, Research
  questions
• 3 IPR disclosures from ANAPAYA

• Review of detailed updates, wrt :

  • Clock accuracy,
  • Configuration requirements,
  • Enrich requirements on several components,
  • Details on APIs,
  • Scalability aspects (trade-offs in terms of resource overhead
    Vs. Path discovery)
  • Clarifications on MAC computation (Mandatory MAC computation
    algo)
  • Security considerations (Detailed description of AS collusion
    attack, PKI, Path hijacking, size of MAC field, PATH stitching,
    DoS attacks)

• NASR ==> BoF this morning, similar use cases as SCION, difference in
  the fact SCION focuses on inter-domain, no PoT in SCION

Questions

• Next steps ? ==> ISE review fro core specifications, depending on
  feedback, see if evolution from core specs is interesting to PANRG,
  bringing deployment experience to research group
• Call for document review to get feedback (with difficult questions)

SCION Open Research Questions (Juan Garcia Pardo)

Talk

• Motivation:

  • Internet scale issues/questions
  • Feedback from developers and operators
  • Goal to standardize SCION as a path aware network

• Research questions

• Reminder on path discovery
• Beacon selection ==> How to communicate a path set with a ranking
  function? Preservation of each AS's "privacy" wrt policy.
• Segment dissemination ==> Avoid incompatibility, privacy of the
  policy
• Reverse path refreshment

Questions

• Antoine Fressancourt: Are you just willing to work on the questions
  or are you interested in listing the possible solutions (for
  instance on private path selection) ==> Intersting to get solution,s
  focus on questions for now.

• Hesham El Bakouri: Have you thought about LLMS in SCION? ==> There
  was a talk some years ago. Explored textual descriptions of what a
  network looks like, to then get map this to network properties (e.g.
  latency), but then there was no further work in that direction.

• Hesham El Bakouri: Which part of SCION is ready for standardization?
  ==> There are still some fundamental questions to be addressed
  before getting there (e.g. how many ISDs, how they are)? We are
  trying to lay out these questions here.

SCION Deployment Experiences (Nicola Rustignoli)

Talk

• Experience gained in early deployments, e;g. in field of banking.
  Lessons from deployment ==> give first answers to questions listed
  in RFC about open questions

• Some ideas about:

  • Deployment model (gateways <=> feasible at scale ? )
  • Operational guys / governance models for ISDs, with associated
    policies
  • Running an AS (with management of crypto aspects)
  • Connection between ISDs

• At this step, some ideas, would be interested in getting feedback /
  expression of interest

Questions

• Colin Perkins: There are clearly some interesting problems, is your
  goal to document the issues or do you want to use this community to
  help finding solutions from the community? ==> Sharing experience at
  this stage, going further if there is interest. (Colin) It would be
  useful to get the early adopters to show up and present their
  experience. Not sure how to do that (Nicola) Easier for people to
  show up in Europe, as the community is there mostly. Link with NASR
  issues to mention
• Jen, relaying a chat comment from Mohamed Boucadair: Interesting to
  document deployment experience (The deployment aspects mentioned by
  Nico are interesting (including logistic matters such as
  bootstrapping an TRC/ISD, application porting, etc.). That would be
  useful to consider here. The same document can include also how
  SCION answered to questions in 9217.) In general, people are
  interested in getting operational feedback
• Jen: Have you considered presenting at RIPE ==> SCION is already
  trying to connect with this community

Path Energy Traffic Ratio API (PETRA) draft-petra-path-energy-api (Luis M. Contreras)

Talk

• Motivation: visibility / observability about power consumption of a
  path. API to be consumed at a controller, customers...
• REST API, and associated YANG model
• Rationale: Lots of discussions about retrieving energy consumption.
  Not a lot of proportionality in energy consumption wrt traffic, may
  evolve in the future with evolved equipments.
• Path energy depends on length, traversed equipments, bit rate...

• Changes from -00

  • API refinements
  • YANG module
  • Jan Lindblad as co-author

• Next steps: Feedback from RG, propose this work a proper home:
  keeping n PANRG? switching to GREEN ? API implementation ongoing in
  Telefonica

Questions

• Michael Welzl: It is just an API, but is there any description about
  how this info is retrieved ? ==> Not in draft, retreival using
  openConfig
• Michael Welzl: are you assuming proportional traffic consumption?
  Yes
• Gen Chen: Energy consumption: real time or longer term? ==> Rolling
  average, real tm eis too variable
• Nicola Rustignoli: How do you envision thi sinformation being
  consumed ? ==> Basically reporting now, for operators. Information
  could be used for routing, but not with this mechanism.
• Michael Welzl: suggestion to add certificates about "greeness" of
  traversed routers (static information).
• Jen Linkova: Do we know how the carbon intensity can be computed ?
  ==> Info (static) from an external system aside the router to
  complement info from the router (dynamic information).

Academic work on path verification protocols (Antoine Fressancout)

Talk

• Motivation: There is currently interest in path verification
  mechanisms and proof of transit in the IETF (including in the nASR
  BoF).
• This work compares different proof of transit and path validation
  approaches in terms of security properties and overhead. T
• Header overhead: Generally, more security features require longer
  headers. When verification is performed at intermediate nodes,
  header grows linearly with number of traversed nodes. Some schemes
  introduce probabilistic mechanisms to mitigate this.

• Performance impact (cryptographic overhead) is summarized in
  spreadsheet, based on manual counting of the cryptographic
  operations. A Kernel implementation of one of one proof of transit
  mechanism was used to verify the counting method.

  • Setup mechanisms: DH-based mecanisms are generally slower, DrKey
    (ETH) uses symemtric key pre-distribution...
  • Data transfer: one mechanism (ICING) uses public key crypto and
    is impractical to operate due to overhead. Pre-established
    symetric key mechanisms were therefore considered.
  • Comparison OPT/SCION extension EPIC

• Key takeaway: based on experience with their kernel implementation,
  proof of transit is feasible. There are several mechanisms to
  provide good security properties while limiting cryptographic
  overhead.

Questions

• Stuard Card: does schemes revieed require prior establishment of
  trust?
  ==> Usually schemes come with key distribution mechanisms to
  establish trust