[11:58:20] --- ggm has joined
[12:03:45] <ggm> CHAIR(s): Geoff Huston <gih at apnic.net> Sandra Murphy <sandy at tislabs.com> AGENDA: 1) Administriva 5 minutes - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - Scribe? - Blue Sheets - Agenda Bashing 2) WG Status Report 10 minutes Chairs 3) Certificate Discussion (Geoff Huston) 30 minutes A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-02.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-02.txt This will discuss the latest version of the resource certificate draft and report on the status of a trial implementation of resource certificates. 4) Certificate Policy and Certificate Practice Statement (Steve Kent) 30 minutes Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cps-irs-00.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-00.txt and Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cp-00.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-00.txt This will discuss both a certificate policy for a PKI used for resource certificates and a template for a Certification Practice Statement (CPS) for an Internet Registry. 5) Route Origination Attestation (Sandy Murphy) 30 minutes Discussion of route origination attestation issues. CHAIR(s): Geoff Huston <gih at apnic.net> Sandra Murphy <sandy at tislabs.com> AGENDA: 1) Administriva 5 minutes - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - Scribe? - Blue Sheets - Agenda Bashing 2) WG Status Report 10 minutes Chairs 3) Certificate Discussion (Geoff Huston) 30 minutes A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-02.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-02.txt This will discuss the latest version of the resource certificate draft and report on the status of a trial implementation of resource certificates. 4) Certificate Policy and Certificate Practice Statement (Steve Kent) 30 minutes Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cps-irs-00.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-00.txt and Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cp-00.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-00.txt This will discuss both a certificate policy for a PKI used for resource certificates and a template for a Certification Practice Statement (CPS) for an Internet Registry. 5) Route Origination Attestation (Sandy Murphy) 30 minutes Discussion of route origination attestation issues.
[12:03:55] <ggm> wow. that was ugly.
[12:04:51] --- sidr has joined
[12:06:39] --- florent.parent@gmail.com has joined
[12:07:53] <ggm> milestones & status
[12:08:28] <ggm> looking for volunteer to write draft on idr security in this architecture
[12:08:48] <ggm> Steve Kent & Sue Hares volunteer
[12:09:10] <ggm> route origination attestation. glacial progress on draft
[12:09:34] <ggm> have to get routing security arch submitted by march
[12:09:54] --- richard.barnes has joined
[12:10:28] <ggm> resource certificates is cooked. no serious issues raised on list.
[12:11:29] <ggm> Resource Certification Profile
[12:12:16] <ggm> http://www3.ietf.org/proceedings/06nov/slides/sidr-1.pdf & http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-02.txt
[12:12:27] --- mlepinski has joined
[12:12:28] <ggm> not ordinary PKI certs.
[12:13:00] <ggm> express right-of-use relationship. issuer attests ranges delegated
[12:13:07] <ggm> collections of components, called resource-set.
[12:13:55] <ggm> intention is that structured certificate issuance follows resource allocation. chain through registry.
[12:14:15] <ggm> each party makes certification under allocation DB info. precise match to allocations
[12:14:41] --- uijterwaal has joined
[12:15:25] <ggm> profile from RFC3280. not the bis revisions, if any, will have to take them, and rfc3779, also not believed to be revised.
[12:15:52] <ggm> general constraints.
[12:16:01] <ggm> 3779 extensions are critical, MUST
[12:16:03] --- rono has joined
[12:16:27] <ggm> no overclaim.
[12:17:00] <ggm> resource cannot be issued to 2 separate entities
[12:17:34] <ggm> during key rollover, there may have to be subject duplicate issuance, but the entity must be the same
[12:17:47] <ggm> cert fields, listed.
[12:19:52] <ggm> Russ White Cisco Q
[12:20:19] <ggm> when to turn CA off, 'on by default' -do we need guidance about turning off CA bit?
[12:21:47] --- florent.parent@gmail.com has left
[12:22:05] <ggm> Steve Kent Q
[12:22:31] <ggm> scope of CRL is all certificates issued by this key. under rollovers, the CRLdp will change to follow new key
[12:24:09] <ggm> summary: narrowing of choices from 3280.
[12:24:29] <ggm> Revokation profile.
[12:24:55] <ggm> Current Activity
[12:25:39] <ggm> AIA, was immediate cert, make it persistent across re-issuance, but not re-key. pURL
[12:27:05] <ggm> Refinements to profile
[12:27:17] <ggm> eeCerts are one-time. use key, and destroy private key
[12:27:33] <ggm> eeCert SIA exists, points to the one thing signed.
[12:27:52] <ggm> Steve Kent
[12:28:05] <ggm> think analysis of implications needed.
[12:28:19] <ggm> implies de-aggregation of certs, more certs being created.
[12:28:37] <ggm> look at routing tables, assess implications
[12:30:23] <ggm> based on use-once princple, looks like many more eeCerts needed to do things with suballocations
[12:30:46] <ggm> Geoff amount of origination by blocks is 30-50000. not that many downstreams. text useful
[12:30:51] <ggm> Brian
[12:30:59] <ggm> mandatory requirement or suggested. (key destroy)
[12:31:07] <ggm> Geoff not mandatory. good practice.
[12:31:53] <ggm> control validity of signing, unilateral revokation, eeCert 1:1 gets that. otherwise, shared-fate with all objects and cannot withdraw one without withdrawing all
[12:31:58] <ggm> Brian give rationale
[12:33:26] <ggm> Review comments
[12:33:30] <ggm> Jabley asked for example of use
[12:33:43] <ggm> Can subordinates have longer lifetime than parent?
[12:34:47] <ggm> Keysize SHOULD : minimum or absolute?
[12:35:21] <ggm> SigAlgs, should we include upgrade options on SHA to 384, 512
[12:35:54] <ggm> Stephan reissue parent, longlife subordinate is maintained.
[12:35:58] <ggm> Geoff yes, thats the intent
[12:36:10] <ggm> making AIA pURL, then reissued in time, no subord reissue needed. the ref is valid
[12:37:26] <ggm> Why RSYNC as MUST?
[12:37:29] <ggm> deliberate.
[12:37:44] <ggm> pain of changing-fetch alg/method in other spaces led to this
[12:37:48] <ggm> all you need is one tool.
[12:37:57] <ggm> Can use other URLs (list) but there MUST be the one (rsync)
[12:38:02] <ggm> Next Steps
[12:38:05] <ggm> gen 03 version
[12:38:11] <ggm> request WGLC
[12:38:35] --- bnsmith has joined
[12:38:49] <ggm> Nem Con.
[12:39:08] <ggm> Using Certs. (informational progress report)
[12:39:51] <ggm> reliable infrastructure for assertions on address use. encompass IRR, any publication of address info
[12:41:11] <ggm> underpin the integrity of address resource distribution structure.
[12:41:29] <ggm> exercising judgement on address/assign validity is expensive.
[12:43:19] <ggm> F/OSS code made available
[12:43:39] <ggm> platform is OpenSSL. work by ISC, funded by ARIN.
[12:43:52] <ggm> 3779 extensions added. given to OpenSSL project
[12:50:23] <ggm> Steve Kent.
[12:50:35] <ggm> worry about retrofit data into existing datastructs.
[12:50:44] <ggm> registries can have data in them, certs only attest to resource holdings.
[12:50:57] <ggm> don't want to create sitation where seeing sign implies trust. HAS to be checked
[12:51:18] <ggm> Geoff yes. have to validate. existence of signature is not of itself enough.
[12:51:36] <ggm> Steve have to be very careful, educate people. will draw wrong inference. seen it happen in signed email
[12:51:42] <ggm> Geoff noted
[12:52:11] <ggm> testing "how big does this get"
[12:53:25] <ggm> Sandy Murphy
[12:53:55] <ggm> many more prefixes adv than allocated
[12:54:06] <ggm> sign roas for everything, not yet adv.
[12:54:41] <ggm> how does AS65000 know the person really is ISPx, entitled to adv. don't they want email signed by PK? but, you just destroyed it?
[12:54:59] <ggm> Geoff. no, this is good enough.
[12:55:19] <ggm> Steve Kent.
[12:55:48] <ggm> What Sandy is asking, is, if I engage in e-comm with my ISP, how do they know that the info I provide, claim to be a particular subscriber of the ISP, is correct, so they bind the (valid) ROA info to the subscriber.
[12:55:59] <ggm> Geoff. signing identity, to transmit, sure, use certs.
[12:56:06] <ggm> but NOT the resource cert, use an identity cert.
[12:56:26] <ggm> use id certs, this doesn't help you. BUT the content, would be 3779. and not neccesarily private
[12:56:42] <ggm> Steve don't have to use the same key. up to ISP to decide what mechanisms are adequate
[12:56:58] <ggm> passwords, website access etc.
[12:57:31] <ggm> Geoff. it gets back to examples of use. tight context. do not use 3779 for secret comms, id stuff, they only exist to sign about address, not about entitites. this doesn't address entities.
[12:57:49] <ggm> Sandy. somebody has to figure out good guidelines for ISPs to do this.
[12:58:26] <ggm> Steve Kent
[12:58:33] <ggm> http://www3.ietf.org/proceedings/06nov/slides/sidr-4.pdf
[13:12:04] <ggm> Pwilson. wondering about use of CPS, independence of RIRs. come to their own conclusions about how to do things. wondering about potential for RIR decisions to conflict with provisions of CPS, allocation policies wrt certificates, and how to handle
[13:12:25] <ggm> Steve. CPS is per issuer. get to write your own. its a template, designed to give each issuer an ability to declare what they are doing.
[13:12:28] <ggm> then can compare
[13:12:32] <ggm> Pwilson ta
[13:12:48] <ggm> Brian Wiess. think its neccessary work, inf. RFC seems right to me
[13:13:05] <ggm> dont understand the process
[13:13:14] <ggm> Steve. hesitate to use the term 'enforce'
[13:13:26] <ggm> publish CP, 1) we like to have perm archive form of docs
[13:14:17] <ggm> enforcement isn't the word. if grossly inconsistent with policy there would be recourse, but ..
[13:14:58] <ggm> Russ Housely
[13:15:34] <ggm> think the two previous Q are summarized as "this is CP, will be used for rescerts. CAs which chose to issue certs will reference by OID., will also write CPS to state how they meet requirements in CP, given them template'
[13:15:40] <ggm> Steve good summary. minor diff
[13:16:43] <ggm> Taijii from JPNIC. CP/CPS, helpful to build trust infrastructure for community, planning
[13:17:28] <ggm> Steve: yes. confidence building
[13:18:04] <ggm> Sandy CPS uplinks, talks about keygen, pvt key prot. have heard different suggestions about how this might proceed. one they make their own key, other made for them
[13:18:36] <ggm> Steve keygen on-behalf, outsourcing decision, should be invisible to the community. common in commercial PKI
[13:20:18] <ggm> Rout Origination Attestation
[13:20:33] <ggm> Sandy 3 presentations. Geoff on content first
[13:21:05] <ggm> EE resource certs
[13:22:15] <ggm> special-purpose signing certs.
[13:22:31] <ggm> sign one thing. generate eeCert,(pb/priv keypair) use, then destroy privkey
[13:22:44] <ggm> inside eeCert is SIA field, points to object signed.
[13:23:02] <ggm> now, as ROA originator, can control validity of object by controlling eeCert. revoke, anything signed should fail
[13:23:30] <ggm> certificate(s) plural or singular, because will have to use more than one, to sign things bulk across all the 3779
[13:23:52] <ggm> because no joining under different TA allowed, so have to multisign to get ranges under different TA merged
[13:25:03] <ggm> info required in ROA.
[13:25:22] <ggm> origin-AS, IP address set, period of validity, <validation data>
[13:25:59] <ggm> validation data confirms, addr set is valid, generated by holder, not altered, == ROA is valid
[13:26:22] <ggm> Steve K. Q
[13:26:49] <ggm> lists origin AS. is one enough? circumstances where ISP has multiple AS, wants to list all may adv. more, change mind, no need to re-issue ROA to do it?
[13:27:10] <ggm> Geoff yes. some ISPs run collection of AS
[13:27:45] <ggm> Steve only if one ISP?
[13:27:53] <ggm> Geoff yes. should be single entity
[13:29:07] <ggm> Steve secondly, when talking about auth.. cert for prefix should be validating assertion like ROA for prefix or subset. wonder, if from safety standpoint, want exact match, not subset. if suballocated, and parent can still cover, then risky. require exact match, remove one way for a whoops
[13:29:13] --- bnsmith has left
[13:29:22] <ggm> Geoff. expect opinion
[13:29:31] <ggm> Simon Lienen
[13:29:36] --- asonalker has joined
[13:30:31] <ggm> steve kent, convincing
[13:30:46] <ggm> Volker more-specifics and covering, need to be able to work together
[13:30:51] <ggm> ie need both exact and prefix
[13:31:33] <ggm> Geoff. industry needs the flexibility. constraint will stop it
[13:31:44] <ggm> so its prefix for now.
[13:32:09] <ggm> Steve confused, if hold cert which covers less specific, can always gen certs you need to correspond. have to consciously do it.
[13:32:10] --- stefans has joined
[13:32:48] <ggm> Geoff, will get awful lot of certs
[13:32:50] <ggm> big issue
[13:33:04] <ggm> two things. policy here? deliberately not in this ROA stuff.
[13:33:13] <ggm> secondly, should ROA be explicit to map to actual adv. or any in covering set?
[13:33:34] <ggm> Steve what has to show up in stds track doc, how to validate one, alg has to make clear if covering or exact.
[13:33:39] <ggm> second is how to match adv.
[13:33:42] <ggm> informational.
[13:33:46] <ggm> two separate docs can deal with that
[13:34:38] <ggm> <?> in some circumstances wan tconstraints
[13:34:48] <ggm> better to take to operational community
[13:35:07] <ggm> Geoff. in current form, says nothing about what you adv. just 'within' the AS set. op community can use any way they want
[13:35:48] <ggm> eg backup provider: only announce more specifics. main: announce /24s, don't want aggregation. do in cert, or do way done now? how much in certificate space? how much in this tool? suggest keep tool focused, don't overload
[13:35:56] <ggm> <?> better as option than default.
[13:36:05] <ggm> goes against operational practice
[13:36:08] <ggm> Volker.
[13:36:27] <ggm> response: didn't get. where u suppose operators communicate particular routes used?
[13:36:44] <ggm> Geoff in ROA, says "particular routes, drawn from that address set, any way origin AS wishes under contract"
[13:36:52] <ggm> not 'adv enforcements, as described here
[13:37:15] <ggm> Volker. seeing scenarios, people want to allow routing very particular sets of prefixes eg CiDR,
[13:37:21] <ggm> Geoff particular adv, prefixes.
[13:37:38] <ggm> Volker if ROA is not place to express this exactly, set of routes to auth, Q is where to do it?
[13:38:05] <ggm> putting in, text, semantics to allow for more specific definitions, probably isn't that hard. make mech for validation more complex but.
[13:38:23] <ggm> if not done here, defer to another level, security Qs will come up
[13:38:33] <ggm> Geoff different Qs. permission is now there, its about the specificity
[13:39:09] <ggm> Volker. large address block sub-divided, has parts with different policy, some aggregate policy, can't express in system being proposed.
[13:39:29] <ggm> either miss potential to define specific auth, or allow?
[13:39:59] <ggm> Geoff. example. understand where coming from big ISP with /16, I get /20 provider based, go to another provide,r ask to route. they say 'comes from big' I give $$$ big says ag being chopped up. my traffic.
[13:40:06] <ggm> people do this.
[13:40:15] <ggm> place policy here, those games cannot be played
[13:40:22] <ggm> real question is more meta. what do you want from the ROA.
[13:40:32] <ggm> want permission to originate, then its policy free validation instrument.
[13:40:39] <ggm> we can go there. we can put policy statements/flags there.
[13:40:46] <ggm> these and only these, no more specifics, etc.
[13:41:00] <ggm> but would say its policy flag. if allow one policy, then others come. cross a boundary
[13:41:08] <ggm> not validation, nowpolicy.
[13:41:26] <ggm> Larry Blunk
[13:41:41] <ggm> allowing more specifics seems to allow path naughtyness, give correct origin AS, but then play with path.
[13:41:48] <ggm> Geoff. no protection from lie in the path.
[13:41:55] <ggm> Larry but with existing announce can do it
[13:42:02] <ggm> Geoff no proxy to policy to fix lie in the path.
[13:43:09] <ggm> Still holes.
[13:43:17] <ggm> Larry some help
[13:43:22] <ggm> Geoff shores up one door, bashing on all 4.
[13:43:45] <ggm> WIlliam Liebzon
[13:43:48] <ggm> (is <?>)
[13:43:56] <ggm> dont want policy in this
[13:45:11] <ggm> Geoff didn't say that. can put it in, but you get more than seen here
[13:46:10] <ggm> will take to list.
[13:46:42] <ggm> Info comes from..
[13:46:53] <ggm> AS comes from ROA.
[13:47:02] <ggm> IP adr set doesn't have to be in. can be derived from the eeCert used
[13:47:09] <ggm> so ref to eeCert is ok, can place there, or reference
[13:47:38] <ggm> Steve
[13:47:47] <ggm> until we got to the trust anchor set.
[13:48:36] <ggm> (np)
[13:49:46] <ggm> refs, certs in roa, or hashes from certs
[13:51:02] <ggm> this one is small
[13:52:21] <ggm> properties change. bigger ROAs, all data in-hand. smaller ROAs, more lookup
[13:53:31] <ggm> Brian Weiss
[13:54:06] <ggm> started at different point
[13:54:54] <ggm> considered SteveKent earlier presentations, ML information, 3 different representations
[13:55:12] <ggm> explicit type, to allow for expansion to other things.
[13:55:24] <ggm> explicit version
[13:55:46] <ggm> adr blocks, or pointers. (explicit or covering TBD)
[13:55:51] <ggm> AS number(s)
[13:55:59] <ggm> validity interval, and siglist, including pointers
[13:56:04] <ggm> design considerations
[13:56:06] <ggm> started with size
[13:56:27] <ggm> wanted extensibility.
[13:56:30] <ggm> opensource to make/use
[13:56:34] <ggm> and canonicalized
[13:56:46] <ggm> clearly describe which things, in what order, signed
[13:56:50] <ggm> formats considered
[13:56:54] <ggm> TLVs, ASN1, XML
[13:57:23] <ggm> simple header, tlv set for type version,
[13:57:48] <ggm> ASN1, can import many other definitions. much open-source.
[13:57:52] <ggm> SEQ of. instance
[13:58:32] <ggm> Russ
[13:58:39] <ggm> confused by what reading
[13:58:51] <ggm> see, blob, and one or more sigs over blob.
[13:59:00] <ggm> already have structure to do it (CMS) why invent another
[13:59:08] <ggm> Brian take under advisement
[13:59:28] <ggm> XML.
[13:59:45] <ggm> basic ROA .dtd is simple. sigspec from 3275, sig XML added during signing process
[13:59:48] <ggm> lots of XML in application space
[14:00:29] <ggm> did comparison with same data. two prefixes, two AS,
[14:00:40] <ggm> size: TLV 286 ASN 445, XML 1654
[14:00:44] <ggm> all extensible
[14:00:51] <ggm> only XML, ASN open-source
[14:01:01] <ggm> both XML ASN canonical, TLV required work
[14:02:56] <ggm> comment from me on ASN1 being bigger than TLV. this would improve with better encoding rule choics
[14:03:01] <ggm> Brian but OID expanded it
[14:03:54] <ggm> Conclusion: ASN1 the best compromise
[14:04:07] <ggm> middle size, tools, best extensible
[14:04:17] <ggm> work on 00 draft
[14:05:04] <ggm> Sandy Murphy ROA issues
[14:05:36] <ggm> communication/distribution
[14:06:16] <ggm> was single repos, now distributed, collect and merge.
[14:06:21] <ggm> also can do in-line in BGP
[14:08:02] <ggm> Auth Model
[14:08:13] <ggm> deal with route origination from prefix holder PoV
[14:08:29] <ggm> RPSS, 2725 uses diff auth model. both prefix, and AS holder must auth
[14:08:46] <ggm> historical?
[14:09:41] <ggm> Owen Delong suggest attack, badguy might be able to usurp.
[14:09:54] <ggm> operational problem. not routing problem
[14:10:01] <ggm> but, should we consider it?
[14:10:26] <ggm> Volker
[14:10:35] <ggm> within RPSL context, 'dont touch it'
[14:10:51] <ggm> but for newly designed system, just addressholder, single auth is right.
[14:11:09] <ggm> problem that has been described, operational checking of path is the interesting thing. cannot be addressed by roa
[14:11:13] <ggm> Geoff
[14:11:20] <ggm> two issues.
[14:11:30] <ggm> don't overload ROAs -they can't easily do path validation.
[14:11:46] <ggm> secondly, in terms of charter, RPSEC was meant to deliver us goals etc. informal view, "happy little campers"
[14:11:53] <ggm> undecided about path, happy about origination.
[14:11:55] <ggm> Owen is on path.
[14:12:15] <ggm> this is about lying about origin AS connectivity. its about path.
[14:12:48] <ggm> when we know what path validation, lets go there, but until then, out of bounds. RPSEC haven't decided, lets not second guess. I am patient. wait for them to die, and hand work over
[14:13:02] <ggm> Sandy
[14:13:08] <ggm> some disagreement on problem characterization
[14:13:28] <ggm> Steve RPSEC attendee. still alive
[14:13:46] <ggm> have mixed feelings. agree with observations. interpret ROA as auth to originate, correct, don't need second sig
[14:14:06] <ggm> problem is twofold. interprete them correctly, incorrect inferences can be drawn.
[14:14:19] <ggm> concrete example is path attack, splice into path. understand not addressing it
[14:14:30] <ggm> second sig wouldnt fix ALL the path attack
[14:14:39] <ggm> appreciate RPSS, but best put off to additional data struct. not ROA
[14:14:55] <ggm> Volker. when discussing Q like this, should make sure, origination here is fake
[14:15:11] <ggm> need support in routing proto
[14:15:24] <ggm> Sandy whole other problem
[14:15:57] <ggm> Chair of RPSEC responds
[14:16:12] <ggm> Sandy. no security requirements statement on Path
[14:16:16] <ggm> Russ White.
[14:16:44] <ggm> as path validation is a requirement, but what it means may depend on who you are
[14:16:47] <ggm> Geoff. thats a punt
[14:16:53] <ggm> moving it over here?
[14:16:58] <ggm> Russ, only partial punt
[14:17:13] <ggm> Sandy. prediction of when?
[14:17:32] <ggm> Russ should be at final call. before next IETF.
[14:17:57] <ggm> helpful?
[14:18:11] <ggm> Geoff. can continue discussions. path is a requirement, but havne't said what path should be
[14:18:39] <ggm> Russ. there are two types you can do. you should/must do one of them
[14:18:48] <ggm> (of path validation)
[14:19:30] --- ggm has left
[14:21:18] --- uijterwaal has left
[14:23:16] --- healthyao has joined
[14:23:58] --- healthyao has left
[14:36:25] --- stefans has left
[14:39:09] --- mlepinski has left
[14:40:36] --- richard.barnes has left
[14:55:44] --- frank has joined
[14:56:05] --- frank has left
[14:56:36] --- sidr has left: Computer went to sleep
[14:57:24] --- rono has left
[15:18:57] --- asonalker has left
[15:57:56] --- stefans has joined
[16:00:12] --- stefans has left
[16:52:06] --- sidr has joined
[18:02:33] --- sidr has left: Computer went to sleep