Minutes for SIDR at IETF-92
minutes-92-sidr-2

Audio times taken by observation from audio player.  Meetecho timestamps taken
from Meetecho chat entries

audio URL:
http://www.ietf.org/audio/ietf92/ietf92-parisian-20150323-0900-am1.mp3 Meetecho
URL:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_SIDR&chapter=chapter_0

audio archive time: 0:05:55  Meetecho timestamp (slide 7):  00:11:23

Chair Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-2.pdf

audio archive time: 0:14:50  Meetecho timestamp:  00:14:48

*** RPSL SIG : Brian Haberman

Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-1.pdf

Sandy (Chair): The RIPE region has an RPSL database with a trust model (APNIC
does as well).
   How does this work correspond with the authorization/trust model for
   existing IRR databases?

Brian: Robert (co-author) is very familiar with RIPE and believes this is
compatible

Sandy (Chair): It is not common in the IRR world to follow the trust model.
   Do you think these signatures will provide a substitute for using this trust
   model?

Andrei : The current system for authentication/authorization is on input and is
completely invisible to outside parties

Andrei : If you have a route object with only one signature, is it valid?
          In the existing trust model you would need two authorizations, right?
         A: What we are mandating is that you must follow the 3779 attributes
Andrei : Understand but do you require two signatures for a route object, to
follow the trust model?

Volk: You have a nicely signed RPSL object, but you can't get into the IRR
database because the RPSS authentication is botched due to some maintainer
object is missing/broken
   Are you suggesting we remove some of the constraints of the existing system?
    That is, if RPSL sigs validate, but RPSS authorization does not validate,
   will the system be changed so that the object can be entered into the
   database?

Brian H: That will require more discussion in the RIPE region.
    We currently see this as complementary to existing practice

Kaveh (RIPE) : Is Aut-Num authentication required in the RIPE region or is it
just an operational practice?
      Volk: YES, it is required in the RPSS

Sandy: In IRR databases that do not use RPSS authentication, we have
reports of people sneaking in objects for prefixes they were about to
hijack.  If you only have one signature on route objects, that would
continue to allow that behavior.
       A: You could have two attributes, one for each authorization.
Or one certificate that included both resources.

Tim B (RIPE): I think that there is a technical solution where we allow
something into an IRR EITHER if RPSS authentication succeeds
     OR if it has valid RPSL sig as per this document. However, that would be a
     policy change to be discussed elsewhere

George M: The practice for how these RPSL sigs are used, is outside the scope
of this document.

Kent: This is in conflict with the current Repository RFC (which says all
signed objects for a cert must in the repository)

audio archive time: 29:32  Meetecho time stamp:  00:30:32

*** BGPSEC Protocol : Matt Lepinski

Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-6.pdf

Matt Lepinski explained changes to bgpsec-protocol that arose during
WGLC.  See slides for detail.

Sriram asked re: the detail (eg per update) of deferred validation visibility. 
Matt explained that he was trying to avoid offering a specific recommendation. 
No further discussion.

Ruediger: made a case for per-session policy versus per-AS policy.  Wes George:
in the route policy, you might also want to specify policy about an AS in the
path.  Matt will propose text to Ruediger, Wes, and the list re: this is a
place for knobs.  Ruediger: this is obvious.  We expect to be able to define
policy per-session.  John Scudder: yes, it's incredibly obvious, but you should
probably say it anyway.

Randy: Wes is confusing two things.  Documents in other areas say that
you can specify for a peer or a set of prefixes, whether the markings
will be placed on the received path.  That is different from deciding
to apply policy if the path includes an AS number.

re: possible signature attack.  Sandy: agrees that there's nothing to
see here.  Wonders if a way to distinguish the two types of blocks
would be useful for debugging/packet capture.  Matt suggests: send text.

Issue 4: signing the AFI.  [missed lots of discussion; Rob had a point
re: current code and AFI]

John: I wonder if SAFI should also be there.  Matt: This version of
BGPSEC only covers the AFI of IPv4 and IPv6, which means SAFI is not a
concern.  Rob: There is a SAFI -- the only one allowed is the null SAFI
- hash the non-existent byte.

Doug Montgomery: We briefly discussed to have BGPsec only use MP BGP -
so no multiple encodings of v4 and v6, and where it is getting the
hashes, so we could simplify things by saying all NLRI are carried in
the MP extensions.  AFI is already in there.

Jeff Haas: One of the reasons why SAFI is a good thing to include is
that when it is time to support VPNs later we don't have to revise the
protocol to change the validation strategy of what we sign.    (Matt
says: future proofing.)

Doug Montgomery: The fact that we have separated origin and path
validation means that we could at some point need to support other AFI
or SAFI, so a good idea to make it possible now, to use later.

Jeff Hass: Pretty much all code treats the non-MP case (IPv4 unicast)
as MP anyway.  For common procedural stuff, instead of treating it as
null 0, treat it as the 1 SAFI, so even in then you are still
consistent even if it is in a different part of the packet.

Rob: John commented privately that there is no such thing as the null
SAFI in BGP.  But there is in the RPKI.  In RFC3779 - the SAFI is an
optional byte and in the RPKI as deployed that byte is required to be
absent.  So you will have to deal with the fact that there is no SAFI.

Matt jumped to issue 7 re: mandating support for multiprotocol
extensions.  No objection to requiring RFC4760 support.

Issue 5: NLRI trailing bits.  No objections.

Issue 6: AS migration.  Jeff Haas: another way to look at this is:
you're adding another signature on ingress.  Matt thinks this is a
better way to present it.  Wes George requested some help making
as-migration say the right thing.

Matt expects that the draft will be shipped to the IESG following
these changes.

Sriram asked for clarification re: issue 5.  Matt clarified that this
is NOT an on-the-wire change.  Jeff Hass points to RFC4271.

audio archive time 1:00:09  Meetecho timestamp:  01:04:02

**** 6487bis : Richard Hansen

Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-0.pdf

Rob A: The bit about EKU is slightly over-specified.
       "routers and other devices"

Geoff H: Rob, This is an already-accepted errata

Geoff H: Isn't this taking two bites at the same apple
         Isn't this about rejected errata being reconsidered?

Kent:  Errata were deemed inappropriate as errata (since they were technical),
not that they had no merit

Geoff H: The second errata, the discussion on the SIDR list decided to reject
the proposed errata

audio archive time: 1:10:30  Meetecho timestamp:  01:14:03

**** Delta Protocol : Tim B

Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-3.pdf

Note: slides used in the meeting were an old version:
https://www.ietf.org/proceedings/92/slides/slides-92-sidr-8.pdf

Kent : We should have clear (not informational) documentation
somewhere as to exactly what the replying parties MUST do in order to
understand the security properties of the system

Rob A: We don't have this type of documentation for the existing fetch protocol.

       (Not to say that we shouldn't, but such relying party documentation
       shouldn't
        hold up this rrdp specification)

Tim B: would prefer to keep this document clean.  Text should take care not to
restrict
       relying parties more than necessary.  Maybe, if wg agrees, we could
       write a document and share it with the wg.

Rob A: For my implementation the server side is further along than the Relying
Party side.

Wes George: HTTP vs HTTPS?
     Tim: I would prefer not to use HTTPS, since HTTPS and CDNs are not friends
          The objects have object security so discovery should not
          We don't trust withdrawal messages (if it hasn't been revoked or
          removed from the manifest then we don't forget about it)

Wes George: There needs to be more discussion. There are worked examples out
there of HTTPS with CDN
       Documents have a burden of proof as to why they don't use HTTPS

Rob A: We are hesitant to use HTTPS because we aren't sure whether or not the
CDNs will support it
       We are happy to do HTTP since pervasive HTTPS is the world we live in,
       as long as it doesn't break the protocol

Jeff H: We don't care about privacy, but we should want integrity of the
transport session.  Problem
        is also withholding object or getting a stale object.  Look at lesson
        of SMTP where bootstrapping stuff in a non-secure environment and that
        being meddled with.

Tim B: We aren't saying we will never use HTTPS, but it seems like a decision
we can postpone

Volk: The object security is fine.
      If I can't trust that I am speaking to the right server, then I can be
      DoS'ed (in "nice" ways)

Tim B: The same concerns apply to Rsync, which did not address these issues

Chris (Chair): The HTTP vs HTTPS issue won't be resolved today. We should have
that discussion on the list.
        There are a number of corner cases that need careful examination

audio time:  1:44:25  Meetecho timestamp: 01:45:10

**** BGPsec roll-over : Brian Weis

Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf

Kent:
     I am two minds with regards to the last slide.
     If it is compromised, then probably both keys are compromised
     So this mechanism is probably most useful for replay protection
     Is it worth doubling the number of router keys/certs in the RPKI, just to
     solve this replay issue? However, maybe if we have separated origin from
     transport in SIDR, then maybe it makes sense to have origin vs transport
     keys

Need more comments on the list. (List has been silent on this for a while)

If there is a heirarchy of dependencies then we are after bgpsec pki profiles
and bgpsec algs

audio archive time: 1:57:28  Meetecho timestamp:  01:57:24

**** Survey on RPKI/DNSSEC : Matthias Wahlisch

Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-4.pdf

Randy: For DNSSEC without a single root, I have to manage hundreds (or today
thousands) of trust anchors
          ... this just isn't possible
       With RPKI, it is only 5 or 6 which is managable.

Di Ma: From the Chinese Internet community. My team did similar work.
    I received feedback, from several networks in China
    "The RPKI has operation risk"
    I believe that the LTA-use case / suspenders work would help address these
    concerns

Sandy: In China, do operators typically use IRRs for route filtering in China?

Di Ma: They [network operators] believe that RPKI is more powerful
    [This seems to imply that making routing decisions based on IRR is not so
    common]

audio archive time: 2:15:40    Meetecho timestamp: 02:16:18

**** Extemporaneous Presentation : Rutiger Volk

Discussion of AS Zero ROAs

My take is that people are surprised to see ROAs pointing to AS zero

I am surprised that we haven't seen other people using AS zero ROA'ing

RPKI gives us the capability to declare certain address ranges to be invalid /
unused

At some point in time, there was discussion in this group that certain
organizations should issue AS zero ROAs for address space where there should be
no BGP advertisements

What looks a bit strange for one certain prefix, two ROAs, one says valid for
my AS 4320 and the other says AS zero
 ... This is a regular operational procedure that got stuck somewhere

I have a policy for only announcing the maximum aggregate prefix for my PA space
  ... but I ran into a few places where we need to split

Make before break ...
  ... for splitting a PA aggregrate, first you inject the more specific route,
  but before that
      you do the documentation (IRR and RPKI)
  ... then remove the covering aggregrate, and finally remove the documentation
  (IRR and RPKI)

I extended the ROA, I created the route objects, I looked a bit ahead and said
I would eventually need a AS zero ROA for the aggregate that will no longer be
advertised.
  ... Let me put out the two ROAs simultaneously, to make sure that no
  implementations blow up
      (better to try it now when there is very little on the line)

Also, I have been busy and so this experiment lasted longer than I intended

Terry M: Did you anything you did agree or disagree with RFC 6907 Section 3?
        As an author, we should re-visit if we prohibit anything that operators
        find useful

Volk: I do not believe I am violating any specifications

Rob A: I believe that everything that he did was legal ... though perhaps a
demented use-case

Doug M: The goal is that in any transition scenario you never pass through
Unknown
      ... seems reasonable to me

Randy: Two major problems with RPKI deployment and then one more minor thing.
      ... Most Egregious: Operators who issue a ROA for their 16 (and clobber
      customers who have 24,
          but don't have ROAs)
      ... Two: Group Trust anchors, where the manifest expiration is different
      from the trust anchor expiration

Rob A: (interjection) 3 of 5 RIRs have had trouble with this (the manifest
expiration problem)
       Some implementors have chosen to have the EE cert expiration very close
       to the Manifest Next Update time
          ... This is dangerous if you are down for the weekend etc (for RIRs,
          this makes all the region ...          go poof)
       Use a longer expiration time for EE cert (so manifest can go stale
       without expiring)

(back to Randy):
      ... Three: As RIPE and LACNIC scale up, we will eventually have scaling
      issues with the transport mechanism

Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with an
operational comment to toss it into the Wiki

Kavah: K-root anycast address space has been signed in RPKI