Meeting minutes are attached in txt and pdf formats. Thanks to Sriram for melding his notes with the etherpad notes.
The jabber logs are available at http://www.ietf.org/jabber/logs/sidr/2012-06-29.html http://www.ietf.org/jabber/logs/[email protected]/2012-06-29.html The etherpad notes are available at http://grenache.tools.ietf.org:9001/p/notes-interim-2012-sidr-4 The participant list from the webex session is below. The jabber logs of course note those who participated in the jabber rooms. --Sandy WebEx participants list: 1. Secure Inter-Domain Routing Working Group [email protected] (Sandra Murphy [email protected] 2. Anuja Sonalker [email protected] 3. K. SRIRAM [email protected] 4. K. SRIRAM [email protected] 5. Matt Lepinski [email protected] 6. Ruediger Volk [email protected] 7. Padma Krishnaswamy [email protected] 8. brad dreisbach [email protected] 9. Jay Borkenhagen [email protected] 10. Luke Berndt [email protected] 11. Andrei Robachevsky [email protected] 12. Carlos M. Martinez [email protected] 13. Brad Dreisbach [email protected] 14. jgs [email protected] 15. Doug Montgomery [email protected] 16. Arturo Servin [email protected] 17. Heather Schiller [email protected]
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: Didnt 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: Dont 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 Ill 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: Well 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 dont 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 dont 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: Robs 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 Robs message. None of the known
implementations use combined ID. Anyone has a comment if combined ID should be
retained in 6485.
Randy: I dont 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): <t>
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. <t>
---------------------------------------------------------------
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.
<Some reports from some who have hearsay of who is likely to be there at the
July 27 interim.>
---------------------------------------------------------------
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.
meeting-minutes-Jun29-2012-v2.pdf
Description: meeting-minutes-Jun29-2012-v2.pdf
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
