Minutes IETF105: sidrops
minutes-105-sidrops-00
| Meeting Minutes | SIDR Operations (sidrops) WG | |
|---|---|---|
| Title | Minutes IETF105: sidrops | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-08-21 |
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.