Meeting Minutes, June 29, 2012, SIDR Interim Meeting (virtual only) Topic: Grand Parenting Draft Randy: Encourage people to send in more/better examples. Sandy: What I call shared authority ? Grand Parent (GP) can produce authority for Child (C) or Grand Child (GC). Are people comfortable with that idea? Chris: Didn?t we talk about that early on? Randy <-> Chris Morrow: Discussion of DNS and RADB grandfather capabilities - RADB allows grandparents to act, DNS is mixed: you can serve names for a child, but if A delegates to B, and B won't act for C, A cannot act. Sandy: Suggest administrative process for GC to contact GP? Randy: Don?t think you can prescribe business transactions. Ruediger: We do not have a general idea what the existing or past relations between the parties are. Sandy: Question: If someone has a cert from the parent, but the parent is not acting to refresh the cert at the refresh intervals, and the ISP is then stuck. Can someone with the ability, up the chain help with this problem? (Someone had asked her about this at a NANOG.) Randy: One common natural occurrence: child of an RIR has a bunch of children, child starts going out of business/real word situation, and is not maintaining the data. Children are feeling the hit. Can the grandparent act in this situation/ or does the grandparent assume authority to act? I can see grandparent leaving the GC certs in place and just issuing ROAs. GP may say to GC, send me a letter signed by your CEO and I?ll act on it. Ruediger: Something (automatic?) can be in place for covering emergencies. I do not just want to accept cert but want to have pre-defined rules what is going to happen in case of emergencies. Party downstream from RIR/IRR should have rules what they can do in emergencies. It does not preclude the paper game. I would not have the whole world relying on that. Randy: GP can have an administrative process put in place before hand. We might very well ask some of the well known GPs (ISPs) to put such a process in place. Sandy: Any of this administrative process stuff needs to go into any of the drafts? Randy: There are some good examples here that can go into the drafts. Sandy: Is the GP I-D informational? Randy: I intend it as informational. Ruediger: Informational is fine. If we do a grandiose good job, it can be a BCP. Randy: This stuff is different enough from what some people may be thinking. So it is worth documenting. Some of the use cases could be reassuring for people who have questions/concerns. Sandy: We will see later if we need to pump it up to BCP. May be, Best Expected Practice (BEP)? Because no one is doing it yet [in real world]. Ruediger: Jay may be doing it already. Jay (Jay Brokenhagen): Not that I am aware of! But it is a way to enforce. (He has in the past allocated address space to people who then walked out with it.) Present enforcement is ineffective. New way of enforcement ? a chief benefit to origin authorization. Randy: Anyone who wants to co-author the GP document is welcome. End of discussion on GP document. --------------------------------------------------------------- Topic: Discussion of pfx-validate document Sandy: Authors have said there are some comments that they have received that they can work with. Tim Bruijnzeels? comment about stating the assumption that the list of ROAs is complete (email on SIDR list). One of the authors said that they can put it in [note taker: put in the assumption in the document?]. Randy: I am personally of the opposite inclination. I think you cannot know if it is complete. Sandy: It is a distributed asynchronous system. Intent is as complete as possible but no way to be certain of it. Randy: Origin-ops doc says in Sec. 6, ? ? distributed data ? distributed caches ?? Do you want it copied into the pfx-validate doc? Sandy: You cannot point from standards to informational doc; that would not work. Randy: We?ll bring in that paragraph from the origin-ops to pfx-validate doc. --------------------------------------------------------------- Sub-topic: Discussion on 4-byte ASN (in continuation of discussion on pfx-validate document) Sandy: Origin ops doc says, ?It is not reasonable to expect RPKI-based validation to run on routers which do not support four-octet AS Numbers, as it is not reasonable to generate ROAs for AS 23456.? Randy: Step up a level higher. No one is doing RPKI/BGPSEC if they are not already doing 4-byte ASN. Sandy: It was not about those doing origin validation in real-time on routers. It was about 2-byte only ASs that are using filter lists. Ruediger: If an AS has old hardware that can't take an upgrade to 4 byte AS support, they probably don't have the ability to use large filter lists anyway. Also, tools need to support translating 4 bytes ASes to 23456 for routers that are 2 byte only. Sandy: Suggest rewording of this in origin-ops document and opening up a discussion on the mailing by suggesting text. Randy: In pfx-validation doc, say what is said at the bottom of p.7 (i.e., ?An implementation MUST also support Four-Octet AS Numbers, [RFC4893].?). Origin-ops needs to say that tools used to employ 4 byte AS RPKI data for 2 byte only routers (other than running pfx-validate) need to be able to translate 4 byte ASNs. Sandy: Any other topics we should discuss related to pfx-validate? Randy: IPR concern from Warren. --------------------------------------------------------------- Topic: IPR concern regarding pfx-validate document. Sandy: I pointed out to Warren that that it was discussed on the list in 2010. It was somewhat of a sore point with a couple of people. Question to WG: Is WG willing to work on IPR encumbered technology. John: Insane for IETF not to be working on IPR encumbered technology. Almost everything is IPR encumbered. I find Cisco licensing terms to be reasonable. Sandy: Earlier no one had objected to working on IPR encumbered stuff. That is why the ROA-validation document went through the IETF rfc process [in spite of Cisco asserting IPR against it]. Randy: See what is going on in NV03. John: If you don?t know, then better stay clear. Sandy: Will speak with Warren to get over his ?grumpiness?. Randy: Will make all the changes [discussed so far related to pfx-validate and origin-ops]. AS4_PATH is not used (mentioned) in the draft. --------------------------------------------------------------- Topic: Keying/Rekeying Sandy: Any one has any opinions keying/rekeying (rogaglia-sidr-bgpsec-rollover)? Randy: None of the authors are here. Sandy: Arturo [Servin] might have a comment. Arturo: No. I did not cover any of that. Randy: It is an informational document. Presenting a piece of advice about rolling keys for a sequence of ops that is considered prudent. Sandy: Low response to call for support. Randy and Steve Kent supported. Steve had extensive comments. Randy: What about the provisioning draft? Sandy: Yes, the bgpsec-rtr-rekeying draft ? Sean, Keyur, Randy are co-authors. Randy: Sean requested WGLC. Sandy: Should the docs (bgpsec-rtr-rekeying and rogaglia-sidr-bgpsec-rollover) be combined? Randy: Should not be combined. Randy: bgpsec-rtr-rekeying draft is prescribing actual data being transferred on the wire for getting stuff into/out of router. John ? do you have any comment; are you going to pull a key off a router or push a key into a router? John: I don?t know. I need to talk to implementers. Randy: Whether one allows a private key pulled off a router and sent over a wire to be pushed into another router? What is the security threat? Should we really not be doing it? Sandy: Ask people with experience in router security issues. Randy: Steves are OK with it but they are not vendors. Randy explains that ?Steves? refers to the set {Steve Kent, Steve Bellovin, Russ Housley, and Sean Turner} ? the IETF routing security people. Randy: Should this require multiple implementations before we decide on it, per routing area style? We are not saying routers MUST do this. We are merely saying that this is the wrapping/packaging that should be used if you should choose to implement either of the two methods (in the bgpsec-rtr-rekeying draft). Sandy: You need interoperability if you pull key from one router and push it into another router. Is it not like a profile? Randy: I should ask the ?Steves? about that. Do we need inter-op discussion? Is proof needed in order to push the draft through rfc process? If it is considered a profile then we do have an inter-op requirement. Sandy/chairs take action to ask wg if they think interoperable implementations are needed, and ask routing ADs to see what they want to see, and ask security gurus the question about standards and profiles. --------------------------------------------------------------- Topic: CMS Sandy: Rob?s email about ?RFC 6485 is inconsistent with base CMS specifications.? 6485 sets algorithms for certs, crls, cms (all the signed objects), and certificate requests. The identifier for the signature algorithm is the same in all cases - a combined digest+signature algorithm. But CMS has its own mandated signature algorithm identifier and it is not the same. All implementations use the CMS mandated identifier (and so 6485 is not compliant with CMS and implementations are not in compliance with 6485). Sandy: This is not a change of technology. It is a change only to the identifier. Randy: We should be deciding if it should be errata rather than re-write the RFC and get a replacement RFC document out. Sandy: Geoff has not replied to Rob?s message. None of the known implementations use combined ID. Anyone has a comment if combined ID should be retained in 6485. Randy: I don?t see a win. We need to get the author of 6485 involved. Sandy: Randy and Rob will contact Geoff. Alexey said that we need errata whether we stick with the RFC or reissue a revised RFC. --------------------------------------------------------------- Topic: Discussion of origin-ops document Randy: I may have a couple outstanding comments that need to be addressed by IETF time. Sandy: If publication points are hosted in the address space they secure, bad things can happen. Randy: Implementations tend to go with existing on-hand data. Sandy: But they won't be able to get new data - either new authorization (ROA) or removal of old authorization (revoked ROA). Randy: If you want recommendation that ops place critical part of infrastructure outside their close control, not likely to get adopted. Chris: Not different reliability requirement than other services - could just note the problem and suggest ops should use their usual reliability tools. Randy (suggesting wording for the origin-ops doc on the etherpad): Operators should be aware that there is a trade-off in placing an RPKI repository whether or not it is in address space for which the repository's content is authoritative. On the one hand, an operator will wish to maximize control over the repository. On the other hand, if there are reachability problems to the address space, changes in the repository to correct them may not be easily accessible by others. --------------------------------------------------------------- Topic: Discussion of bgpsec-ops document Sriram: The concerns about local-as/replace-as/as aliasing/as migration/ might induce changes into the bgpsec ops. At this point, the group devolved into discussion of loca-as/etc issues and Wes George's message of June 28 on the mailing list. Sandy: How does the trust model for using pcount=0 relate to aliasing use of pcount=0 ? will the AS checking the pcount=0 be in a position to judge the AS applying it. Sriram: Left AS could apply pcount=0 and right AS (in aliasing pair) does the checking. Randy: Are you implying an ebgp session in the egress router? Sandy: Could be an ibgp session between left and right. Randy/Sandy: But ibgp sessions don't apply sig attributes. Sriram: (1) Need to ask whether pcount=0 would suit the requirements of existing uses from Wes's message, and (2) What the trust model is ? who trusts whom? Can we assume that the members of a migrating group of ASes know of each other so they would be in a position to trust pCount=0 from each other (as appropriate in a migration scenario)? Ruediger: Don't think we want to talk about ibgp here. Quite clear to me that the replacement for the current knobs that make the AS migration/aliasing etc. needs to be replaced with new knob that does the pcount=0. No final decision as to whether that is going to work or not. I think what we need to do is to describe how the pcount=0 would work and then ask implementers how well that fits with existing code. John (in answer to Randy request for opinion): I think Ruediger is right - a small matter of programming. Knobs in question are not currently standardized, so odd to standardize a change to them. But still the methodology needs to be documented. Randy: Suggests pushing all this out to bgpsec-ops. Ruediger: We might want to go the standards route, unless the implementation is strictly in-box, we don't mind, but technique needs to be defined. So I need to bring remove-private-AS knob to standards. (Knob says whether you remove it or not). In Cisco implementation, remove-private-AS removes private AS if the private AS is in the path. Not sure about Juniper version whether it is the same. Randy: Removing ASes in the middle - really hard to do. If it did not sign to me, can I strip it and forward sign elsewhere? RANDY: CORRECT WHAT I WROTE, NOT SURE I GOT THAT. A-B-private-C, B signed to private and thus is not supportable Ruediger: Some cases may be too complicated to standardize. John: About Randy's first case (private AS in the middle) - think not supportable in bgpsec. Sandy: If no protocol changes are needed, do we need this to be in the protocol document? Or some other document (bgpsec-ops or some specific local-as/etc document). Rudiger: If requirements document mentions this, ok to provide resolution in ops document. Particularly, if ops document also has implementation requirements section. Randy: implementation requirements sounds like standardization which is John's point - knobs are not currently standardized. Ruediger: Ops document can capture what needs to happen in box. Ruediger: Can we have one vendor/implementer during the full day interim before IETF in Vancouver. Randy: 6th Jun meeting was missing the security folk and the vendors. --------------------------------------------------------------- Topic: Future meetings Small discussion of upcoming interim dates: pre-IETF (Vancouver) announced. List from March mentioned meeting around RIPE - the large interim meeting date has moved to 29 Sep. After that, nothing scheduled. Need to judge need for more interims (NANOG/ARIN in October?) by progress of drafts.