SIDR WG

June 26, 2007, 9AM

Minutes by Paul Hoffman
(Read the slides for more depth)

Agenda was bashed

1. Action items left over from IETF68 SIDR WG meeting

• Steve Kent to consider CAs issuing overalpping certificated to different entities: considered
• Sandy Murphy to consider rsync as a registered URI Type: would ential direct or third party registration
• Paul Hoffman had the comment about being specific as to CPS text that should be changed. Noted that provided clear indication where text is to be provided.
• Joe Abley investigated RIPE database structure vs use in other RIRs (posted 20 Jan 2007)
• Paul: Question as to architecture as informational or standards track: no clear resolution so far.
• Steve Kent to add test for 4-byte ASN in ROA format. done.
• All: match of NLRI to ROA? done.
• All: Document use cases in architecutre draft.

2. CP/CPS update - Steve Kent presenting

Changed in the draft:

ERX: how it is represented
Added discussion of manifests
Added local cache maintenance for RPs
Gave overview of the protocol
Added:
Subject name conventions
Discussion of default trust anchors (IANA? RIRs?)
ERX
How RIRs deal with early registration
Need to add discussion of how to match prefixes and ranges by algorithm
Need to create a separate document on repository operations
Added semantics and syntax for manifest
Per-CA signed blob use to detect active attacks against the repository
Local cache management for RPs
Suggestions for how to manage
Operations section
Added discussion of when you don't need a cert
Dealing with 4-byte ASs and 2-byte ASs
Question about matching ROAs to BGP updates
Maybe we need to break the one-to-one mapping between the ROA and signing certificate
example case of a /19 announcement based on /20 prefixes with different validation paths
revise the ROA spec to allow ROAs to be signed by 2 or more EE certificates.
Lots of people have read the draft

3. CP & CPS for RIRs & CPS for ISP - Steve Kent

Removed references to certificate acceptance by Subject

Certificates are being issued as a side-effect
Subjects don't even ask for a particular name
No commitment process
CPSs are usually written from a template
Suggestion to not take anything else
Steve is concerned that not enough people are reading the CP
Wants each RIR to review the document

4. Resource Certificate Profile - George Michaelson

Humorous comment on bordellos and the meeting room
Background overview
Most important: do not give out more than you have authorization to give
Lots of language cleanup in -07
Suggestions for revision

Remove SubjectAltName
Require PKCS#10, allow CRMF for interactive
Issuer determines the subject name
Rsync is mandatory?
Question about why Subject CommonName vs AltName
Can the name be present but NULL?
No; at least stick in maybe a hash of the public key
Yes; it doesn't matter because the issued cert will have a unique name
Made a bunch of normative changes (see the slides)
Next steps
One more round, then WG last call
Not as many people have read this document as the architecture document

5. ROA Format - Matt Lepinski

Overview of ROA design and use
Changes since -00

Now only include IP address prefixes, not ranges
Added an "exact match" flag for how the owner can announce
Described how a ROA is validated
Open issues
Need more detail about how to compare IP address ranges
Maybe requiring exact match on prefixes is too restrictive
Proposal to add a boolean flag for ExactMatch
Discussion of use cases and needs for range matching for smaller ranges
Discussion of pushing RPSL into a ROA
Where do we stop? RPSL is very expressive
Is this enough for the policies we want, or do we need more?
Balance complication vs. expressiveness
General view that existing boolean allows for particular policies to be expressed by the set of enumerated of exact match permit ROAs, so that min/max prefix size constraint in the ROA is not required - the boolean flag is considered to be adequate here

6. Private Address Space - Sandy Murphy

What should people do with RFC 1918 address space?


1) Don't announce it at all
2) Use a local trust anchor and SIDR

For IPv6, the issues are similar but different due to unique local addresses (ULAs)


IPv6 WG is discussing registering ULAs
Maybe these will be chosen by RIRs

Should we add this to the architecture draft?

Do we want to wait for ULA to finish?
Question about why this is even a question

Should the architecture document even cover this?

Maybe IANA needs to leave it as an unsigned delegation

Related question: does IANA sign 0/0 or not?

More consideration needed on this topic

7. Open discussion

Steve Kent suggested that there where three new drafts that might be written:

Repository structure?
Manifest?
Up down protocol from the RIR?
 
APNIC author group volunteered to edit the repository structure draft
Manifest is already described in architecture document, and no clear support from the WG to work on this as a separate document
Further consideration fo the UP/DOWN protocol as this is not necessarily part of the SIDR charter per se.
Noted that DNSSEC has similar issue as 0/0
Specify in your config file "Space X is covered by trust anchor A" and so on
It's a pruned tree
Good to be able to specify scoping in a standardized way
Comparison of IANA assertions:
1) Everything (and you know what are private), or:
2) Public addresses only
Note that the latter allows someone else to claim they are authoritative for some of the private space in local contexts. This may be a feature.