Chris Morrow & Keyur Patel Chairs

Called to order at 3:55

Sriram - Discussion of WG LC of documents

RPKI Deployment Agenda

1) Amir Herzberg
Analysis of easy deployment validator

Research work we have been doing
- RPKI Deployment: Stauts, Challenges and the Learning-Validator

=
https://www.ietf.org/proceedings/99/slides/slides-99-sidrops-rpki-deployme=
nt-status-challenges-and-the-learning-validator-00.pdf

Questions [at the mic]:=20
   =20
    Sometimes situations are complex as a customer leaves an existing =
transit provider taking IP space with them

Tim - Ripe NCC:
    People can subscribe to alerts for when unauthorized announcemeants =
appear, this has improved data quality
   =20
Rueddiger Volk/DT:=20
    For successful deployment, we need additional tools and monitoring =
deployment.
    We don't have the full tooling and monitoring available we desire
    Do we have the tools in the implementation to cover the customer =
use-case?
    It does not appear that the large networks have the CA roles =
necessary to make this happen.
   =20
???/???:
    If the customer doesn't create the ROA, traffic will still forward =
to the customers
   =20
Carlos/Lacnic:
    Are you taking into account the more specific routes when you say =
traffic would be lost?

2) Jordi Vilanova - [15 minutes]
draft-paillisse-sidrops-blockchain-00.txt

Job Snjiders/NTT:
    I fail to understand what problem we are solving

George Michaelson/APNIC:
    If you lose the private key, you lose the addresses
    You are unable to functionally assert information about your IP =
space without the key
   =20
    Public verification/public ledger is not inherently tied to =
blockchain.
   =20
Rajib/?:
    This would be interesting to do route validation, could we use this =
for path validation.
   =20
    It would be interesting to see how much time/effort proof of work =
takes
   =20
Randy/IIJ:
    Registries are about to assert 0/0

3) Tim Bruijnzeels - [10 minutes]
HTTPS in TAL/TrustAnchorLocators URIs

Randy/IIJ:
    Given the RDP touches, don't I get the address of the certificate at =
the root I can compare to the hash in the TAL?
    What better verification is there?
   =20
    A: RDP URI is given at bootstrap, includes notification XML.  In a =
nutshell RDP doesn't get you there, you could point to notification of =
delta
   =20
    The trust model of HTTP is another whole world..
   =20
Rob/DRL:
    It's good to try to do HTTPS validation, not sure if it should halt =
if we can't do cert validation
   =20
Job Snjiders/NTT:
    It's good to standardize the transport in toolchain.  If we're going =
to modify this, perhaps we add version number with=20
   =20
Dimon/?:
    I'm wondering if the relying party software validates the design
   =20
    A: Even if it's optional choice, I can use a CDN or other things to =
scale.  If the CA decides to use the delta protocol, for that particular =
situation we don't need to call RSYNC.
   =20
    You are suggesting ... optional? =20
   =20
    A: If we can use either, that gets me a long way there.
   =20
Morrow/Chair:
    Can you e-mail the list and ask for adoption?
   =20
    A: Yes

4) Tim Bruijnzeels - [15 minutes]
Signed TAL to communicate URI changes or planned key rools
draft-tbruijnzeels-sidrops-signed-tal-00.txt

Rob/DRL:
    we can look at 5011 for possible solutions
   =20
Randy/IIJ:
    ?


5) Tim Bruijnzeels - [5 minutes]
Update on Tree-validation
draft-ietf-sidrops-rpki-tree-validation-00.txt

Randy Bush/IIJ:
    We have long tradition of publishing RFCs=20
   =20
Rob Austein/DRL:
    This does not need to be WG document, ship it
   =20
Morrow/Chair:
    We should push WGLC and publish the document

6) Randy Bush - [10 minutes]
draft-ymbk-sidrops-ov-clarify-00.txt
[ no slides ]
* there are variants in how routers implement RPKI validation
* two significant problems
** 1) when i make annoumcenet, if the other party needs to say invalid, =
we failed
** 2) the rfc says the operator is in control through configuration of =
what is done once the route is marked NotFound,Invalid, etc.
**    we have implemetnations that do different types of things to be =
helpful, but they are harming the ability of operator to set operational =
plicy

rv/DT:
    I certainly agree we have to expect not everyone is using this =
(RPKI), so I have to deal with situation that some of my customers may =
not do RPKI classification, I still need to tell them they are sending =
me invalid routes.
    I would wonder if adding to the draft a hint that the =
implementations should make it easy to produce the message for neighbor =
that is sending invalids.  Some vendors it's easy, others it's painful.
   =20
    A(Randy): can I do it with policy?
   =20
    Vendors have optimized by not storing rib-in information
   =20
    A: if by policy i decide to drop your route, that should be ok
   =20
Keyur Patel/?:
    RFC6011 doesn't mention rules for redistributed routes, should we =
publish rfc6011-bis?
   =20
    A: If I'm originating the route, what is the ASN?  Confederations, =
local-as, etc..=20
   =20
Jeff Haas/Juniper:
    Do we want to go an extra step and not mark routes by default?  I =
suggest this?
   =20
    A: I don't want this
   =20
Job/NTT:
    Should we update 4271 to say where this should happen in the =
process?

7) Declan Ma - [15 minutes]
draft-madi-sidrops-rp-00.txt

RV/DT:
    For the last paragraph you had up, I would repeat the earlier =
comments
   =20
Morrow/Chair: please send request to list for adoption


8) Oliver Borchert - [5 min]
Update on BGPsec reference implementation and BGPSEC-IO, a BGPsec =
testing
engine

No questions

End 5:32pm