Minutes IETF105: sidrops
minutes-105-sidrops-00

Administrative
Jabber scribe: Warren Kumari
Minute taker: Melchior Aelmans

Chairs:
Chris Morrow
Keyur Patel

Agenda:
    0) Agenda bashing and Chair's slides - [5 minutes]

    1) Alexander Azimov - [15 minutes]
    https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile-00/

2) Daniel Kopp - [10 minutes]
https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-validating-bgp-speaker-02/

3) Tim Bruijnzeels - [15 minutes]
https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal-03/

4) Randy Bush - [10 minutes]
draft-ymbk-sidrops-ov-egress
draft-ymbk-sidrops-ov-signal

Added to the agenda: Diversity (Terry Monderson)

Alexander Azimov -
https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-00 Discussion:
    Job Snijders: Why did you put the derpricate-as-set-confed-set reference on
    this slide? Alexander: it's a good question, it's a question to you, to the
    WG. For a proper as-pat verification we cannot verify as-set segments
    because they are unordered. If we want to get fid of malicious activity
    that may happen in BGP we need to get rid of as-set and thats why it's
    here. i would like to know what happens to this draft and if anyone is
    happy to push it forward. from the security perspective we rely on the
    piece of this document. And the authors of this draft are here. Warren: the
    document is around for a long time. We've decied at some point we start
    another document at one point which depricated as-sets and atom aggregate.
    That seeems to be a much betting thing to do. It remove a lot of other
    things in BGP. Randy might have more to say. I believe the current version
    is ready to be adopted by someone to be adopted. Ki Sriram: I just want to
    add  there is already a version of it which is at BCP which is converted to
    standards track. So hopefully the BCP is helpfull in the meantime but we
    can work on it so see if we can push it through to standards track in the
    meantime Alexander: I would be glad to see if to see if this peace of  will
    get adopted. Ruediger: If nothing else happens as far as I can tell the
    interesting piece is at the end of the path; the as-set. The way it is
    usually constructed is not relevant here at all and if nothing else happens
    one would need to check that is can only happen at the end and then you
    could esessentially just just the regulair path. Assume that the first
    regulair as that shows up in the path and the set is hidden behind it is
    the origin. Becuase all the tricky stuff that happens inside the as-set
    doesn't matter. Alexander: yes I do agree with you. At the moment the
    certification doesn't say anything about if i said in the middel of the
    as-path is uhm if we have a forged as-path we should at least avoid as-sets
    in the middle. I do agree. Ruediger: as far as I've observed them they
    where never somewhere in the middle. There was a good reason for that.
    Unfortunately I don't have, well okay, let me put it into a question, would
    it improve the understanding of the whole thing if we did a part in the
    document that essentially reviels the concept of what is signed in the
    aspa's and the complext as1 use typically consfuses people who don't need
    to work with it and I think that the conceptiual data structure that is
    trnasmitted there and what supposed semantics are could be exposed much
    better and I assume the structure behind the structure and the actual
    encoding might change the concept thats being used Alexander: are you
    speaking about as 0? Rudiger: what is the concept being used? you are
    coding a set of asses and you do you strange trick in case you want to code
    an empty set. Kind of why not actually explain this and then code like it.
    Alexander: I remember we discussed privately, so my idea was when
    introducing as 0 document it was to design similair. I'm not sayaing, it is
    very simply from the perspective of coding, do you have sets or do you have
    as-set records. From implementation side it is nearly the same. Reudiger:
    all small matters of coding agree, for making people understand what they
    are supposed to do and to work well coding implementations can be an
    obtacle and yes I also have another hidden agenda. If we are actually
    coding sets of ASes that means you in the time, the stadard is being
    developed, in a matter of time, in a couple of months the concepts could be
    used by people that agree how to code in other ways available the sets of
    ases that actutally use the ways of technnique kind of imideately.
    Alexander: yeah but anyway generating for example as-path filtering using
    route <cards?> you will end up with some generator of your configuration.
    You will need to make sure you are using <clear?> to configurate..,., It
    should not matter if you are using a set of tuples. Ruediger: The issue
    here is much less the coding which may be slightly easier or harder, it
    doesn't matter. I agree handcoding stuff is out of the question. But making
    the concept that is used transparant to users actually is valuable because,
    while okay, with a little bit of coding the user interface can also
    represent concepts that is kind of hidden to whats happening underneath but
    that does not really help. Kind of for details, offline discussion, makes
    sense. Alexander: thank you ruediger Keyur Patel: if you take as-confeds
    out, do you want to propose what should be done if and as-confeds in
    encounter? Alexander: If speaking about any protection in malitious
    activity a forged as-set mitigates any protection. At the moment the draft
    says to thread it just like highjacks. Tim Bruijnzeels: the semantics are
    identical to what you have in OV hence that you argue to drop invalids. But
    when things are unknown thats okay? Alexander: Yes Tim: does the text
    states something about threating unverifyable things with suspision?
    Alexander: unverifyable is, I think valid Tim: thank you. I asked earlier,
    if there's a as that makes a signed statement, maybe we should think about
    how to make that object. Maybe I want to make 1 object that has everything
    in it and not risk that there are issues with a bunch of object that are
    withdrawn. Alexander: I'm not sure if I get the question, let's discuss
    offline. Geoff Huston: How can I be adjecent to an as-set and might it look
    like? Alexander: I like to state this one more time: the problem with
    as-set is that it is unordered. Geoff: it doesn't matter, it is never going
    to happen that everyone signs so you will have to have partials. Alexander:
    I'm not sure if I get your idea, I will try to reach you later Jared Mauch:
    I don't know how mayne adjacencies I have. I have an unknown number of.
    Alexander: how many upstreams do you have? We are talking about upstreams
    Jared: that might be possible to find out. Alexander: the only thing that
    aspa does, if you create a record it says who your upsteam is.

Daniel Kopp -
https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-validating-bgp-speaker-02/
Discussion:
    Doug Montgomery: Whats the scenario where you get 2 validation results?
    Daniel: if your router is peering with different route servers and there's
    2 giving you different result of the validation for a prefix. Chris Morrow:
    So, there's 2 routeservers at de-cix. I peer with both of then and they
    happen to be unsynced with their perspective of the rpki data, one says
    valid, one says unknown, what shoud I do? Daniel: that would be failure
    scenario Ruediger: these would be 2 different routes with different
    communities. I'm not aware of any configuration language to have
    appropriate polidy language? Doug: I think we have talked about this before
    but not in this context; you have no guarante that the highest value is
    valid? You have no guarentee that it has the most recent data, right?
    Daniel: basically you should favor the higher value Doug: I wasn't
    sugesting a race condition, I'm saying the idea that you choose the one
    with the more faverable validation result isn't a sign that you are
    choosing the one with the more faverable validation result isn't a sign
    that you are choosing the one with the more up to date RPKI information,
    right? Things could be effectively degrading. Daniel: it would be in favor
    of security I think in this case. Chris: I think Doug, your point is, as
    the data in the RPKI is changing over time, I may choose to  authorize you
    to do this route today and Job tomorrow and not you tomorrow. And if the
    data at the 2 different route-servers is in a state where one has the old
    data and one has the new data I sertainly don't want the data with you in
    it anymore. <unidentified> We made an awful lot of test about that last
    year and you can have the following situation; let’s assume you have a
    router on the east coast and a router on the west coast. They exchange the
    data and they have the same path. Both have 2 validation caches. I don’t
    know which ion the validation cash has the most up to date data. I might
    that the one that results in a valid is more up to date than the one that
    has the other result. It also might  be that the one has invalid has the
    more up to date data then the one with the valid so I cannot say just
    because out of security. Because it might be security that cause the prefix
    to be valid so what now?
Daniel: okay I take this as a good comment for the draft.
    Job Snijders: In the case of failure in the OV process for instance, how do
    you define failure of the OV process? As for instance if the cache is empty
    policy will dictate all of them will become unknown and then omitting the
    community is a forge signal in this construct that contradicts with what we
    understand of what unknowns are or not found. So we cannot differentiate
    between a failure in the OV process. Daniel: yes I see the problem as well
    Job: a second comment: If the default is to reject invalids maybe you
    should remove the well-known invalid community and then only 2 communities
    are left; the unknowns and valids and at that point I kind of wonder what
    the use case is of this. Because I think it’s not very valuable and you
    should reconsider the words that “we can trust each other at an internet
    exchange”. I fully agree from a commercial incentive if I where looking for
    an internet exchange. But we in the transit world say “transit is what you
    trust”. Daniel: okay so you should sell…..anymore John Scudder: Now that
    you explained what the last bullet means I would like to agree with
    Ruediger that one route has one validation state. It doesn’t make sense
    talking about having multiple validation states for a route and as I
    understand it sounds to me it should be removed because it doesn’t make
    sense to say the route has 2 validation states. It only has one and it’s
    the one the route server told me. Daniel: okay thank you Randy Bush: I have
    problems with the trust model also but that’s been beaten to death. What
    you switch which community confuses me. We have a well-defined one but
    basically as you see the real problem that’s in the OV signalling draft is
    that as soon the community get to my router it is…..when it’s invalid. And
    the problem is that I want to close withdraw and we havent quite got the
    right semantics for that. Daniel: the community was changed because of the
    comments from the last meeting so I understand that this is the right way
    to go and the default thing that is also done at route server. Otherwise if
    we want to have extended communities like it’s done with the ibgp draft you
    have to implement all the policies and you have to wait like 10 years so we
    thought this is the way to go.

Tim Bruijnzeels -
https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal-03/
    Eric Osterweil: I think this is really good. I like the fact that you do a
    lot of analysis and I would be happy to work with you if you want. Tim:
    Sure Randy: I would like to see early security area reviews and to suggest
    the chairs to find some friends over there. Chair: yes Rob Austein: I think
    prototyping is highly advisable. Maarten Artsen: You talked about keys
    being able to revoke other keys and your security considerations says that
    currently any key can revoke any other key. So I was thinking about these 2
    and I’m wondering if you want to roll a key because you are not sure that
    it’s safe anymore for example. But that’s the property you are looking for?
    But it made me question how that works. I know that in the TLS working
    group I know that they tried to get some academics proof groups look at
    some parts of the protocol. I’m wondering if it’s useful to try and do that
    here with the RPKI bit to try and understand if the properties you are
    looking for are provided by the functionality you are modelling. And I’m
    not sure if anyone is willing and able to do that. But I guess that this is
    the time where you can easily fix oversight. Tim: thank you for the
    pointers so I can use good advise. What we had in mind that if you have an
    HSM you usually well protected against key theft but you might still want
    to do planned rolls because you might want to change hardware and you can
    still loose the key as well. A lot of this relies on procedures.
If all keys can remove each other then you just need to have only one of these
keys to … and clearly that can introduce bigger security risks so I think
there’ s tradeoff here and I’m not sure I have all the answers but I hope the
help of HSMs can help in that regard and strong processes. You need to have
especially processes.
    Sandy Murphy: I have been impressed by the amount of effort it took to do
    the DNSSEC key role so this is a really goo idea to get an early start.
    Thank you very much for starting the work. I also remember the difficulty
    there was in the SIDROPS WG to define the algorithm to change documents so
    what happens if your key role is also an algorithm role? Tim: I don’t know
    Sandy: okay good answer Rob: I haven’t reread this recently. One of the
    things that was a consideration to publish keys that was the ability to
    pre-publish keys before using them. Thats basically because no-one knows
    how to do an emergency key-role. We probably want to put something in it to
    do that. Tim: fair enough

Randy Bush - draft-ymbk-sidrops-ov-signal
    John: I don’t think I like it but I will think about it for a while.
    Job: So you are kind of sticking withdrawals for off link peers into a bop
    community? Because what the Route Reflector thinks its invalid it send a
    signal back to the spoke that could be a well known community or a
    attribute…. Randy: the community is already documented and defined. Just
    saying the semantics aren’t… Job: … treads what it received from the ebpg
    peer as a withdraw and then it will send withdrawals to the other route
    servers. Keyur: No, route reflector when it receives a route from it’s
    clients it will run a best path and will announce a best path. When it does
    the community it tags on top of it says what is wrong with it. Now route
    reflector could say path 1 is the best but path 4 had a bad community. So
    it can do add-path and say this wrong, take it back. The net result is the
    same. Job: The spoke receives the signal, then what should it do, perform
    OV? Randy: the point is, when the spoke receives the signal it withdraws
    the invalid as if it had detected it but it has no cache feeding it. Job:
    in other words this is signalling withdraws over BGP communities? Randy: it
    is signalling asking to withdraw Jared Mauch: And then it decides I have
    seen this again and I’m going to send it back up. This sounds scary and
    messy. Job: if we are going to modify the edges to accommodate the behavior
    then why not just implement OV? Randy: Others want to have centralised
    control.

Randy Bush - draft-ymbk-sidrops-ov-egress
    Job: go on

Terry Manderson - Diversity Conversation
    Florian: It turns out that even if you don’t have a ROA you still have a
    problem because someone can’t get a ROA. Ben Maddison: I presume the single
    operator you refer to is ARIN? Terry: It doesn’t matter who it is. Ben:
    This is presumably assassinated by the fact that all 5 are claiming root in
    the root CA? Terry: not necessary. It would actually also exist if there
    was a single trust anchor. And it could be worse. Ben: So you don’t see
    this being improved from a diversity perspective by having the numbers from
    which the root server come from more widely spread amongst the…. Terry: I
    don’t see it…it’s better but it’s not ideal in my opinion. Job: I have
    trouble grasping the problem; there are 5 root certificates and 26 prefixes
    and you can distribute the 26 under the 5 tals. That is not enough
    diversity? Chris: can you do the numbers for your first 2 RSEP documents
    please? Terry: 0 21 Chris: no not those numbers; the internal numbers like
    the first one is it’s okay if the first root server Terry: ah yeah, the
    first one is it’s okay if there’s one fails the second one is principle
    that sad for the root server operators and that is that the root server
    operators will have diversity in their operations inclusive network and
    stuff like that. Job: so if you sign half of them, not sign the other half
    and distribute amongst the multiple RIRs you’re done right? Terry: I don’t
    know it that the answer that SIDROPS would recommend? Job: is that within
    our mandate? Terry: this is where you operate RPKI and SIDR and stuff. This
    is where your expertise is Job: In that case I would recommend you try to
    transfer at least 1 IPv6 prefix to another region as an experiment to see
    if you can obtain access to other certificates Carlos: we will happily
    welcome you guys. We have policies that allow us to assign prefixes for
    critical infrastructure that can be used outside of you region. And I
    believe the other 4 have similar policies.I don’t believe this is a problem
    for us to solve. I think if you have 9 prefixes within. A single RIR you
    guys are a bit weak on the diversity aspect that you are defending. I don’t
    know what the solution is. I mean you could role IP’s in some of the other
    root servers and distribute them amongst the RIR’s. You can get new space
    from us. You could transfer like Job said. You could create more diversity
    in root server operations. Terry: maybe someone should write a document
    that defines some things that you should do. There is no advise about this
    to date. Chris: maybe the issue is a general network operations problem?
    Terry: I wasn’t making that point but fair. Robert Kisteleki: 3 things; 1.
    I don’t think the root servers are any special in this context. 2. No
    operator can be worse of then today if they also have Roa’s and RPKI. They
    may be better of but they won’t be worse off in case of attacks. I’m happy
    to talk about it. 3. Root operators already sync on protocols and all you
    do so you might want to do IPx or something. Doug: just to be clear so you
    are afraid of ROAs being created that cause other folks to drop your route?
    Terry: it could be anything, it could be operational failure Doug: which
    causes your resources to become unknown? Terry: it becomes invalid Doug: so
    people who filter on invalid can’t reach you on that address Terry:
    correct. Especially if it’s transit that is filtering Randy: I would want
    to refer you to a presentation that is about how to escape ARIN. All my
    resources are at RIPE. Terry: I didn’t mean this to be a beat up of any RIR
    Randy: what I’m saying is that some can move Terry: The point is that the
    diversity is 5. Rob Austein: you are not going to settle this today. I
    think you need to make a distinction between reliability and availability.
    You can probably survive an outage of RPKI not being updated. So you might
    want to do the numbers on how long an outage is acceptable. Geoff Huston:
    You have raised an interesting issue. They are great topics. You should
    consider from the perspective from all 12 of you what you should need to
    get diversity and maximum availability and performance. Maybe invoke
    experts from RSEP. It’s difficult for this group to advise in isolation.
    I’m saying not here and not now. Terry: Where do you think I’m going next?
    Doug: it seems like your risk is the same no matter what decision you take
    because its the other people doing validation. If a CA is compromised and
    someone creates a wrong ROA for your resources whether you take action or
    not? Terry: correct Doug: right. Seem like you can make a decision whether
    you fear route hijacks to the routes more than you do compromise massive
    failure in RPKI. Terry: I think I’ve done enough here; I’ve raised
    awareness Job: what would you propose as follow up on this? Is there a WG
    or institution working on this? If we have a great idea where do we send
    this? Terry: my next steps is to raise it at RSEP. I’m also member so it
    will be raised there. It might be raised in other parts of ICANN. There’s
    additional stuff coming through but I thought it was good to raise it here.