Subject: [sidr] minutes from sidr IETF 73

From: Sandra Murphy <[email-masked]>
Date: Tue, 16 Dec 2008 11:45:57 -0500 (Eastern Standard Time)

Thanks to Roque Gagliano, who took the minutes at the sidr meeting in 
Minneapolis.

The minutes are below.  Please comment to the list of any changes you 
think are needed.

--Sandy

Minutes for IETF SIDR Meeting IETF73.
November 17th 2008. 1300-1500
Salon AB - Hilton.
Minneapolis, MN. USA.

Chairs:
Sandra Murphy
Geoff Huston (participating remotely).

Minutes taker: Roque Gagliano - LACNIC
Jabber scriber: George Michaelson - APNIC

1300: Session called to order.

A) Administrivia
B) Updated Drafts

1) Two presentations by Matt Lepinski BBN Technologies:

a) RPKI Architecture Document (draft-ietf-sidr-arch-04.txt):
- 04 Document out, differences with 03: Improved abstract and
consistency with other SIDR doc. No open issues, please read.
Comments?:
Sandy - Route Filters and semantic issues raised by Geoff (the list
is exclusionary, the issue was raised during the RPSL discussion last
time).
Matt - Not in the current version, need to have private discussion of
how go deal with this issue.
Ruediger - Route Filter Use is not real validation but to implement
policy. For doing this you can use different sources of information,
better if it is good sources. This discussion of what do we do until
we get to the final form of validation has not happen yet (will it in
this century?).
Geoffry Haas - in support, SIDR should talk about create filters from
data. RPSEC work leading should talk about using this data for
security preference. If a network chooses not to use, that should be
fine.
Randy Bush - dont think you want to get into what shades of lipstick
on the pig?.
Matt - The intention of the arch, document is just that the date in
the RPKI can be used as an input for policy desicion.
Roque - Please do not mention DNSSEC and what happened with trust
anchor material information?
Matt - Ok.
Stephen - We need to keep detailed information in only one document,
open to know about which one. The Cert profile version 15 has
reasonable information but we need to keep it in one place.
Sandy- Architecture document do not normally have formatting
information.

a) ROA Format document (draft-ietf-sidr-roa-format-04.txt):
Version-04. Changes since 03:
- Clarified text on ROA validity.
- Addresses in ROA must be a subset of EE certificate Prefixes (not
need for exact match).

RobertK - Currently you can have prefixes overlapping from different
ROAs, the problem is that it can be confusing for implementors. One
implementation takes it as "wrong.".
Ruediger - What is the problem? this can be a feature. I may want to
announce the aggregate and have particular policies for some and not
all the more specifics. Overlapping ROAs should be allowed.
Rob Austein - Now that we have a use for these, I will change the
code.
S. Kent - How does people feel about inherit bit in the ROA. Looks to
us that can be a problem to developers to have those and not the
explicit cert.
Rob Austein - Agreed may be simpler to implement
RobertK - You still need to go up the chain.
Rob Austein - This issue is only for ROAs, do not put in more generic
doc. Leave it in the ROA doc.
Matt - Will take this issue to the list.
Randy - Overlapping Prefixes: Will be working with Ruediger on the
unusual cases. Do we want to give funny code about this?
Sandy - Any harm to overlapping ROAs?
Randy - The code, but it is a consequence of funny arch.
Matt - Hopefully will discuss this on the list.
Other issue: multiple signature proposal, believe there is not
consensus to change.
Randy - I do not consent.
Ruediger - Cases are so rare that I do not consent.
Rob Austein - I do not consent.
Sandy - As a WG chair I also believe there is not consensus for this.

What is the process on for multiple ROA? The ROA draft continue alive
but not consensus on adding multiple signatures to the ROAs.

Russ (Author CMS) - No problem going that way.

Next discussion raised: BOA & ROA ASN=0:

Matt - Transition period, ROA for AS = 0. Can we add text that it
should be interpreted as "should not be routable".
Randy - Fear of manual trust anchor configuration can be a
consequence and we will finish similarly to the current bogon
filters.
S Kent - Unlike BOA during the transition period this idea will not
mean a new mechanism, this is zero changes.
Sandy - Would it require changes in the validation software?
S Kent - NO.
Randy - It would require changes in the BGP path selection in
routers?
S Kent - Maybe.
Ruediger - I would like to have detestation as a way to tell
"everything should validate PKI", also in the transition I would like
to have detestation for things that I know that should not be there.
Dave - Is this the same as BOA?
S. Kent. - What it says is that the origin ASN for this prefix is 0.
Rob Austein - The issue is the semantic in routing that is a
different discussion.
Roque - Ruediger mentioned that want to have a detestation mechanism,
the question is what is he expecting from the RIR when generating ROA
ASN=0 or BOA, that impacts our registration software and may have
consequences in time to route.

Presentation by Stephen Kent from BBN - Certificate Policy document:
draft-ietf-sidr-cp-04.txt

   Thanks comments.
   Stephen explained the meaning of the CP document and particularly
pointed out that this is the one document every party in RPKI agrees
to.
   Changes from version 03:
- inclusion of "bogon" route.
possibility of different signed objects (not just ROA).

Randy: do we need an RFC?
Stephen: not in the current text.
Randy: So I have to agree to accept signed objects that I do not know
its semantics?
Stephen: CP area about issuing Certs by CA.
Randy: What contract am I making?
Stephen: There is no responsibility of the issuer of the Certs on
what it is used to signed. You cannot control what the end users do,
you can point out what the intend is: routing security.
Randy: Do not have problem to make this distinction.
Stephen: will take it to the mailing list.

- Change Cert. Authorities, added IANA.
CP will be co-adminitrated by IANA and the five RIRs.
Mark: You gave it to the RIR and you asked for feedback, what is
next?
Stephen: Would like more participation from the RIR. And listen to
their feedback.
Randy: Why does the document mentions "default-trust-anchor" that is
something that relying party decides.
Stephen: It is normal practice to have that information in the CP,
the "normally used" but yes the RP may decide.
Randy: As it is a touchy issue, please finesse it.
Stephen: Will try.
Paul Hoffman: We need this, as it is common practice in every CP. RP
will like to have as much information as possible in the CP document.
Danny McPherson: There are implications on the decision of the trust
anchors and would like to have discussion in the IETF.
Stephen: I have some slides.
- Key changeover. Includes ISP/LIR, etc.
Randy: there are also LIR to sub-LIR, needs to get the appropriate
text here.
- 6.3.2 trying to explain why the RIR cert change periodically while
IANA do not, but the language needs to be modified.
- Trust anchor material, showed the current practice. Check the new
version of the CERT Profile draft.

End of Presentation. Question section:

Andrei - I apologize for the lack of feedback. The problem is that it
is "tricky". Our legal team is checking it, for the time it takes I
can see it is not a simple thing. I also believe that the doc. goes
to issues that are still "hot discussions". Example, re-allocation
policies are still under discussion. Another thing it states that the
use is "secure routing", but the trust is that we are talking about
"right of use". Can we put it in one page document? we are talking
about different laws, etc.

Stephen - This is the formal for all PKI. You are correct it is not
trivial. If you want to make changes, we are open to receive them.
Not a lot of feedback yet. Can we make it in one page document, NO.
You need to ask people that already reviewed a CP before to check it.
Andrei - The problem is that the standard template takes you to area
you do not want to go.
Stephen - We can have sections that can be moved from the CP to the
CPS which can be regionalized.
Andrei - This is an IETF doc. What would be the status after
approved?
Stephen - After approval will be publicly available.
Randy - Check DNS, for DNSSEC is not PKI and do not need a CP. For
Andrei, the CP is for relying parties to tell them what we are
telling them they can rely on. Feels Sympathy on the concerns but as
a RP likes having CP.
Russ - One of the reason for having this document agreed by all the
parties is that all the material refers to a policy document, and
this is that document.
Danny - Can you explain your comment to RFC3779 and trust anchors?
Stephen - When validating prefixes and ASNs you need on the top a
self-signed cert, with RFC3779 extension, not any CA cert.

C) New Drafts section:

1) Presentation by John Mohapatra - Juniper:
draft-pmohapat-sidr-pfx-validate-00.txt

The idea is: given RPKI, what can the router really do?
A work in progress, several contributions received.
Need a mechanism to differentiate between invalid and legitimate
prefixes been announced.

Maintain in POP authenticated prefix and AS cache database. You can
also have a database inside the router.
The drat talks about the database structure.
BGP decision process changed to compare the lookup result before
LOCAL_PREF.
iBGP vs eBGP: No validation on iBGP sessions.
Can we do it in real time? looking to performance issues.
There may be an overlap with  the roa validation document: the draft
started from a different angle, what can we really do?, finished with
something that has similarities with the roa validation draft.
However there are differences: no "linked validation", #states for
validation outcomes, BGP Speaker validation dissociated from
Database, can work with any database (or data-source), ex RPLS.

Future Work: Work on the protocol bits for interaction in-PoP
database and in-Speaker database.Also, Talking with the roa
validation draft authors to check for possible merge.

Danny - Validation side: What about protecting against hijacking a
more specific?
John - Anything that can be expressed by a ROA can use this
mechanism.
Danny - What about ASN spoofing?
John - Yep that is a problem.
Danny - What about soft-reconfiguration, rate limit for the
connection to the database, that is something that needs to be deal
with. Should I store prefixes that I know are false? Need some
guidance in the doc about what to store and implications.
Randy - Have serious question about scaling issues. Want to hear
about what gears are going to be used. The size of the router that
you expects is critical.
John - This is a policy mechanism.
Ward - The protocol to the BGP Speaker and the PoP Database is it
part of the WG work?. I believe so.
Sandy - Need to check the charter or include it in the charter.

2) Presenation by Robert Kisteleki from RIPE NCC -
(draft-kisteleki-sidr-rpsl-sig-00.txt).

Use of RPKI signatures to sign RPSL object.
Not specific to one object type. Can have multiple signature and that
is helpful for route objects when you can sign by the prefix and the
ASN authoritative party.
Signature in RPSL "like" format to feed back the database.
Some canonization examples shown.
Signature formats: chose DKIM format.
Where to put the signature? "remarks: Signature is" or new attribute:
"signature", may be problem with some legacy software.
Example given.
Open questions:
Multiple signatures?
Unicode?
Sync with other people that are thinking on the same line.

Is there support in the Working Group?

Randy - I believe this is valid work however not the proper working
group. have too much work here.
Sandy - Which WG should be?
Randy - Not recommendation.
Haas - This looks like another WG.
Randy - We are having problem getting our work out.
Henk - Some time ago did some RPSL work and were by individual
submission.
Danny - Need Charter discuss.
Geoff (form jabber) - As co-chair I am in favor of picking up this
document.

Thanks for staying late.

Adjourned.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr