Internet Engineering Task Force 108, 27 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108 SIDROPS 20200727 1300

Description

SIDROPS session at IETF108
2020/07/27 1300

A

Natalie's there and.

A

B

B

Chris can hear me.

A

C

A

Relatively full agenda today, um I think- or I hope that the presenters are all.

A

Here I have a feeling, I'm clicking on the wrong thing to let people speak. It's gonna.

D

A

All right, I think we need a jabber scribe. I can't really keep track of what's going on with the chat and the people that want to talk at the same time, so.

B

A

Ideally, oh okay, good.

A

Yeah so sriram's question about do presenters have to enter the queue before their turn comes. Yes, please do that, and jared is pointing out that as the itf, this list is full of messages about we're getting cut off exactly at the end of the time. So.

A

Why don't we try and get started? Okay, so here at the siderops meeting.

A

We're going to need somebody to take notes, natalie's going to take care of the jabber.

A

All right, I can't keep track of the the presentation and the uh chat so whatever happens, I guess somebody should speak up. One of the chairs, ideally.

A

Okay, there's a note well ideally, you've seen this before. Maybe I can make this not quite so nope that doesn't help great sorry. Okay, we have an agenda, I don't think there's anything else to add to it.

A

Oh sorry, this is the wrong agenda.

A

Well, all right, I guess I just can't make slides properly.

A

Or apparently run a presentation anyway, we have four things on the agenda.

A

The first one I believe, go find it.

A

A

A

Okay, first item on the agenda today is john kristoff. Let me I'll just do.

C

E

Could you expand your slides, please.

A

Now nobody can read that, but me, but sorry I'll fix it later separate jabber client. Yes, I would love to do that. All right.

A

Hey chris, um if you share an application, instead of your whole screen.

C

I can present, I think I can.

A

Stop presenting my screen and maybe john, can present his screen now and give this.

A

C

A

All right, john, perhaps you should just talk and I can do the.

A

Slides look like this as soon as I figure out how to make this stupid thing present again,.

A

Grand audio okay go john.

A

Hello, mr kristoff.

A

Pretty sure we can't hear you john, or at least I can't.

C

This is jeff uh john you'll need to click on the share microphone icon, that is at the top of the screen. It's the microphone that has the little hand or the one that has the little play icon.

A

Okay, let's uh try see if maybe d ma wants to give this a whirl while we work on john's connectivity, ideally.

A

Speak upd and we'll see if we can get your presentation.

A

A

Can I hear you.

A

A

F

This is warren, just testing to make sure that audio does work for someone.

E

Come to a practice session.

A

Oh son of a biscuit.

A

C

So warren we were able to hear you. Fine john one of the things that we have not seen is that you've actually shared your microphone at the top of the screen. Next to your participant thing, there'll be a set of icons, a screen, a video camera and two microphones.

C

If you click on one of the microphones, that will allow you to talk to other people.

E

Is that the icons are in the upper left, but when you hover over it, this tool tip is in the top.

A

Center, hello, hi d.

B

A

B

Okay, so shall I get started, please: okay, um hi folks, um um today, I'm going to brief a draft um rpk validated cache update insulin over https, which can be called rush rush for short during ietf singapore meeting last year. I shared this idea as well as my personal implementation practice to this working group, and also my intention to seek is civilization and the version there there. The draft was therefore submitted in last december.

B

After that we also received some comments from the community and.

B

B

Yes, here is my considerations as for the way of formating data, we prefer to facilitate the data path for both visualization and application other than router origin validation, as well as to take advantage of slum to have some local version of rpk data, and then we choose https as a transport at the end of the day, because https is widely supported, it is with security enhancement over integrity, protection and its political. Then unit independent, well.

B

When I say it's protocol that you need to independent I'm, what I'm getting at here is http is friendly enough to accommodate many kinds of structured data such as json, xml and mml, etc. So next slide, please.

B

The figure on the right of this page demonstrates an example of a russian operation which is essentially to place a solemn file, object in the http message body and use a newly defined video type application. Slash json salon to indicate this extension.

B

So if you are already familiar with ifc 8416, you would find it easy to uh do a cache update by using some filters and slim assertions which are responsible for deleting and adding rpki vanity cache items respectively. So that's the reason why we use json to format a cache data alignment with a file.

B

In another word, we use some file to describe a cache data and its update next slide. Please.

B

um Moving along to this slide, um I would like to reiterate uh why we employ https as a transport um rtr is over there. We know why bother to do this, I'm justified what is all about our motivation.

B

Rtr is designed exclusively for providing rpk cache for routers, so its video is bound to its transport, which is uh which is difficult to add extension to support these uh vanity cache synchronization management well like the dns pdu, is bound to the dns transport. So it's hard to do some extension to uh add to dns okay. uh Well, I see something like uh similarity and second, the binary data unit cannot be passed by application which, by the way, don't support rtr generally, I mean maybe in the in the coming future. We we.

B

We would like to use the vanity cache uh for the uh of their applications.

B

um Https is widely deployed and the data format independent, as I mentioned, and um our rpi advantage. Cache server just needs one api to do both synchronization and local control, since the json is employed by a slump file which, by the way, is uh specified in rfc 8416 to override the global rpk data. Okay, so um I mean, if you, uh if we uh use rush, we can use one just one api to do both uh synchronization and local control.

B

B

um We make a separate section of rush use cases in this version of version. 1 help people to figure out in which circumstances russia can be employed to transfer rpk value into cash, and we also have got three cassie so far and we look forward to seeing more as we pursue is standardization if this working group would adopt it is the case, why uh would be the cash distribution?

B

uh The rush can be used to distribute rpk, even the cash within a single uh yes or network, and a small site or the enterprise network may also use rush by synchronizing with a third-party rpk cache provider over external networks, as I mentioned at the very beginning of this uh speech, use case two, we can use rush to do local control networks.

B

A network operator may want to inject slam assertion or filters via a api offered by rpki, validator or cache provider. So russia is therefore able to carry out such a function.

B

Last one is about the es0 information so um not a long ago. Well, I guess, uh as far as I know, in the ripe community or some discussions on how to use salem file to deliver. uh Yes, their information uh has been discussed and um the the ir needs to publish assertions with origin as0 for all the unlocated and unsigned address space uh for which is uh for which it is a current administrator.

B

uh So rush is able to deliver such uh assertions to rp cavalry line parties if so, called es000 file would be generated by ir, such as epidemic or ripe. Well, I see uh the proposal has been withdrawn by the order in the right community.

B

B

B

um Well, here is my considerations or rush standardization.

B

Rush merely focus on standardized transport and the data format of the rpk cache data. So all we need to do is uh to make a registration of the application. Slash, json, solar media type uh from hyena and uh rush has nothing to do with synchronization. Under the rush and system.

B

We expect the user rush in different use.

B

B

Where the push or pull we used for cache synchronization or how to do resin correlation and access control, well, which, by the way, is kind of kind of different. From what I mentioned in last itf meeting held in singapore, uh when I shared the detail, um the uh with our implementation of rush, so next slide.

B

um For security considerations, um I think.

B

B

Transport and the outer band transit between cache servers and a subscriber. However, this document is not going to expand on this, but leave it to operational practice, lag.

B

B

Okay, um that's all about uh what I'm going to talk about rush so far and I hope it could be adopted as a working group item. So thank you. Any questions.

A

I believe randy has a question.

E

Yes, I find the security considerations quite disturbing.

E

C

E

We have a trust model, it's object, trust and I just don't trust, grant getting stuff from random servers that change my view of the rpki. I like this proposal much better when it was yet more data dangling off the existing trust, anchor.

E

A

Oh disconnected.

A

Okay, I guess you didn't actually have a comment.

A

A

Or not? Okay, let's move on to the.

A

All right come on john and job russell.

D

A

D

uh I would like to echo run those randy's comments on the security considerations.

D

uh It seems to dance around the meat of the issue and specifically in the case of rar, our member, that's crossing trust boundaries, and I do not believe that that should be done without object security. So I think the es0 origination thing is is a bit of a red herring. It is not a great use face.

D

Okay, how do I shut this down.

A

I can kick you out: okay, let's try.

E

A

I think we're out of time for for these slides. I think, if there's real questions here, we should provide them on the list. We can certainly have an interim if we run out of time here or need in the next bit in three or four weeks. We can have an intermediate to discuss this or other topics, so why don't we try.

A

John, let me find your slides.

A

A

And we can't hear.

A

A

A

Okay, john says he's having some problems. Why don't we table his presentation for now and move on to sriram? I have no idea what what the actual order of slides was anymore because I'm lost so can.

G

You can you hear me.

A

G

Okay, actually, oliver is online. Oliver was next.

A

Okay, well, then, we can certainly do that instead.

H

Okay, can you hear me?

H

Yes, yes, uh wonderful, okay, I had some. My internet went down this morning. So uh had some problems. Okay, so um today I'm talking about giving an update about the signaling bgb, seg validation state next slide. Please.

H

So during last presentation we basically proposed to combine rpk origin validation and b2b seg path, validation into the same attribute, as was discussed during the adoption call, but then, when we presented it on iitf 106 in singapore, we had some interesting discussions and um heard some concerns regarding backwatch compatibility and other issues and were asked to basically undo this step.

H

So what we did, we basically removed the proposed modifications to rfc 8097 and we therefore, we removed all the origin validation state so that at the current um in the current state, it's basically just bgb sec, origin validation.

H

Then we added some wording regarding the non-transitivity of the attributes. There also were some concerns, oyster concerns raised, and we added some. um We wrote it. Some reverted a little bit some parts of the peer signaling net next slide. Please.

H

So that is now again the packet format of the extended community.

H

We have, it looks pretty much the same like the origin, validation, rfc, 90 1897 attribute, except that here the validation state as a b2b sec, validation, state, and so the only thing there. What we need to have done is uh we would need the um uh the ti added. The b2b, exec path, validation, state community by ayana into the registry. Next slide, please, so the validation states are unverified for zero.

H

One valid and two not valid nothing changed, and there the valid and not valid, come from the rfc 8205 and unverified basically means that this particular router did not validate, beat or did not perform. Phpsec validation on its own next slide, please so for the non-transitivity.

H

uh What we basically added into the draft is that the router is only or if the router did not perform the bgp seg path, validation on its own then- and it sends this attribute to its peer. Then it must set the validation state to unverified.

H

So what this means is basically, then, if, for example, a particular router receives a validation state via this attribute, let's say it's valid and it does not perform its own validation state. Then it must, if it forwards this update, then it must add the validation state unverified rather than the receive validation state valid, and with this we basically make sure that the attribute stays non-transitive next slide.

H

Please, regarding the peer signaling, we have wording in there. That says basically that each implementation must provide configuration switches for that to enable or disable the receiving of these attribute on a per peer basis that should be by default, enabled on ibgp sessions and disabled on ebgp sessions. Next slide, please uh error handling. We um decided to one actually. That was, I think, since all the time in there um that, if I receive more than one of these attributes, then the complete attribute has to be discarded.

H

The same is true in case the validation state is other than the one of the three specified validation states, and then the router must apply a strategy similar to the attribute discarding rc 7506.

H

I think it is uh next slide.

H

That's it so is there any questions.

D

Of two minds whether things should be enabled by default on ibgp sessions, because we noticed with the hp origin validation, extended communities that exist today, that some implementations made assumptions about whether that community would be present or not. uh Ben madison may be able to highlight the exact details of what the problematic situation was, but yeah. I would be worried about enabling things by default across all http implementations,.

H

That's fine, we can we can. We can certainly uh think of having this by default, all disabled and then having the operator. The the more the more important part for us is that the operator should should have the capability of configuring, the enabling or disabling of the attribute on the purple basis that that is the most important part. For me, um we just were thinking because it makes extremely good sense to have it on ibgp sessions on.

H

So that's why we decided or that's why we added the the the part was it should I mean if, if there's a shot, you always can have it different anyhow, um but yeah I mean there's.

D

No problems you are taking this into consideration or thinking about what the default should be. So thank you for that sure.

A

Ben and then care.

I

um Can you hear me yep yep super, um I think when you oliver say attribute discard you mean a specific community and you don't mean to drop all the communities extended. No.

H

No, no just just this particular one.

I

Right so attribute discard. Typically, if I recall correctly drops the entire attribute, you want to have some text that specifically um references in context of this specific extended community and not the others. That's the only feedback I have. Thank you. Okay, thank you. So.

F

F

Ben here, can you hear me? Okay, yes, yep, so just to follow up on the point. Job was making um the particular issue that we came across when we were rolling out. Origin validation was that the receiving side in one implementation makes assumptions about what the absence of an extended community means, and in that case it was treating anything that it received from an ibgp peer without an 8097 community as valid, which is obviously which.

C

Is obviously stupid.

F

But to prevent a a kind of a new incarnation of that problem, it might be worth spelling out that a receiving ib gp peer that does not receive one of these communities must treat it as having not been validated rather than either positively valid or invalid.

H

Okay, does that.

F

H

um Yeah, I mean the thing. The thing is that I agree to a certain extent. I think, actually, that the attribute the the receiver should not make any assumption on on a pier where it doesn't receive anything anyhow.

H

So so, for example, you could have an implementation that allows you to um specify default validation, states, whatever this validation state is, and it allows it to the operator.

H

So I I I would say that an implementation should not make any assumption whatsoever most likely. It will result into unverified, but should not make any assumption whatsoever about the absence of this validation, state or sorry. The update of this community string.

F

Yeah and and to be honest, I mean the point that I'm making should be sufficiently obvious that the issue would never arise. But, as I say, this is a oh.

H

No, I I I know, I know exactly what I know what you're talking about.

F

Certainly, there are carve-outs that you can make for local policy and so on and so forth, but I think.

C

F

Giving a big red must to potential implementations is not a bad thing, because you know a lot of people got burned quite badly by that implementation, choice and origin validation, and it would be nice not to repeat it.

H

Yeah, um I definitely will go back to that and think about how we can add that.

H

I agree that at least some some wording has to be added to to point out this issue.

H

I don't I don't know yet, and I wanna maybe have this discussion a little bit further offline uh with my co-authors and everyone who wants to join. um If, if that should be unverified, I mean normally, I mean we don't need to make a big deal out of it. You know um but yeah. So at least there has to be a must, not assume any validation, state whatsoever.

F

Yeah absolutely.

H

And unverified is not a validation set, so we only have these two valid, not valid. So okay, perfect.

A

Thanks, okay, okay and I think sriram was next.

G

Okay, thanks. Can you hear me? Yes? Oh thank you, uh okay, so this talk is about uh as hijack detection and mitigation on next slide. Please.

G

So recently, like in june and july, there was an anop thread uh discussing as hijacking real incidents happening in the internet, and there were questions about what operators can potentially do to prevent hijacking if they have a responsibility to do so. That motivated us to think about possible prevention mechanisms for as hijacking as hijacking the definition is as hijacking occurs when one as uses another ass number as the origin asn in a bgp announcement, it could be accidental or it could be malicious.

G

The prefix in the announcement may sometimes belong to the hijacker. The hijacker in that in this case, is an as and it the prefix could be one that normally originates from the hijackers as uh but more often uh or most most likely. uh The hijack hijacker is actually hijacking this as and also hijacking a third party prefix next slide. Please.

G

So rpki route, origin validation, is not sufficient to mitigate as hijacking. uh This slide demonstrates that as1, who is concerned about hijacking of his as number, uh has created all the rovers that that are necessary for the prefixes that that it originates and three uh is doing validation. Two is uh uh it passes?

G

The update passes through two to go to three uh three is doing uh rpki origin validation of four is a hijacker is hijacker in this case and he's hijacking as1 and announcing a queue, prefix queue, which is a third craft party prefix, and it doesn't have a rover. So three basically determines uh that q hat q is not found according to rpki ov, uh and therefore q um could accept uh a three could accept the prefix queue and propagate it.

G

So, as hijacking is successful in spite of rpki origin validation next slide, so we propose a a method in which we propose to create a new rpki object, called reap and reap is used for as hijack detection and mitigation reap stands for, rovas exists for all prefixes rpki object. uh It's an rpki object that is digitally signed by nas, uh the, as is asserting that the rows exist for all prefixes that are originated by it.

G

Object contains only an as number so once uh the reap object is in place. The detection algorithm is fairly simple, perform the rpki ov process as normal.

G

If the result of rpk iov is not found, and the origin, as has a deep object, then replace not found with invalid and mitigation is simply that you reject the invalid next slide please.

G

So this slide demonstrates uh the uh reap concept and also uh it. It asserts that uh the benefit of reap accrues right away uh for the for the ass that are uh that have adopted it.

G

So uh so the fourth for the uh in this picture. uh Let let's talk uh yeah, let's talk through this example. uh As1 basically has created robots for all prefixes that originate either. The prefix owners have created it or as1 owns some of those prefixes uh all rovers exist. It creates a deep object in rpki. uh As3 is validating, two is not participating in reap, so we are considering a partial deployment scenario.

G

um Four is hijacking as1 and announces a third party. Prefix q are two three and three basically looks at the first. Does the rpk iov determines that q is uh uh not found, but when it looks at the origin s with in the route for q, it sees a s1 and it says oh as1 has reap. Therefore, it changes the not found to invalid validation and that's how it detects the as hijack next slide. Please.

G

So the idea in the previous slide was that reap is robust to a robust, impartial deployment scenarios, the ais that wants uh as hijack prevention and the as that is doing reap they both benefit immediately, even though no other ass are participating.

G

uh Here, we are talking about other mechanisms that do as hijack detection prevention, uh bgp set. Does it uh because it requires path, signatures and that prevents as hijacks. uh But adoption uh is a question mark when uh aspa um was. It was designed for route detection and mitigation, but it has. It also: has the side benefit uh that that it can also prevent uh as hijacks? uh However, in partial deployment, it is not robust like repeats. So, as we show in this, two in the middle is not doing aspa, one is doing it.

G

Three is doing it. uh Four can do a cut and paste attack and be successful either with a third-party uh prefix like queue or or it could even be successful with a prefix. uh A sub prefix of as1 originated by as1 like the slash 23..

G

So again, the point is that aspa is capable of airs hijacked detection, but in a scenario when there is partial deployment in this picture, there can be other parts from one two three, but those other parts can make may be feeding uh less specific rather than the more specific. uh So so partial deployment uh is something that is an issue uh with aspa, at least for as hijack detection. But reit is robust in partial deployment scenarios next slide.

G

I think that's my last slide um so anyway. Chris you can hear me.

A

I can't I think I broke my.

G

Presentation yeah.

A

G

Mind it's uh I'm done. The last ride is only a summary and it's not uh necessary. So john, can you can go ahead.

A

I think john uh john bailed out on the presentation. So, let's see.

G

No, I see no john scada is in the queue for questions. Oh.

A

Sorry scutter! Yes, yes, please.

G

G

A

Okay, does anybody have any questions that could actually speak at the mic.

G

C

G

uh We'll be happy to have any uh rudiger just uh came on.

J

um Hi? uh What uh resilient remark?

J

Some people are making a major argument uh about. If a ca fails, uh everything will be fine because uh well, okay, it means essentially that uh uh route origin validation goes into uh unknown state.

J

I don't really subscribe very much to the argument, but there are people who are making a lot of about it.

J

We have to expect that the cas and the related three segments uh for the as and the addresses actually are different and if you have a failure of the address, ca kind of reap will essentially, if, if a reap.

J

End as object is in the, as ca will essentially invalidate uh all of the as announcements.

J

And that's at least something that has to go into the security uh into the securities uh considerations, because it is certainly a point of attack.

G

Oh, I understand the question yes, uh so thank you. We will put that wording in the security consideration.

G

uh The thinking uh we had on our mind was that uh if uh one type of rpgi object like rova is not available, then potentially uh reap is not also available and and things and it will remain in not found state rather than go to invalid, uh but certainly uh your point is well taken and we can include that in the security considerations section. Thank you.

A

J

Thank you and let me just add the remark that uh I think there has not been a lot of discussion about how the cas for a s number space and address number address. Space should be related, but I think it makes a lot of sense to cons to expect that cas, for both spaces in many cases will be different.

E

Only with the biggest isps um the schroeder points out a serious problem, but he attributes it to ca failure. It is also our p failure. Rp does not reliably fetch from row a publisher but fetches from um the publisher of whatever this object is, I forget the name already and disaster happens.

E

This is um significantly common. If john had managed to give his presentation- and I believe the risk is sufficient- that um I cannot in any way support this proposal.

A

Can I ask a clarifying question: randy? Sorry, chris?

A

Okay, um you don't support it today, because there are rp problems and potentially ca problems if the rp can be significantly rp set can be significantly cleaned up so that they understand this failure mode and deal with it appropriately.

A

It doesn't seem horrible as an option.

E

Unfortunately, john presentation failure obscures that the relying party universe out there is scary.

A

Okay, I think john said he has a or could make a pre-recorded thing to share for.

E

A

Later so that would be better yeah.

E

But essentially, but essentially um relying parties are not overly reliable and.

E

I don't think I don't think that going down that path is going to be a success path. I think. uh Yes, we have to clean up relying parties, but I believe we're looking at years.

G

So chris, thank you for your response to randy's question. uh Only other thing I want to mention is that this reap object is something that is signed by the as owner, and that is same as the aspa object. So whatever considerations apply to aspa also apply to reap, and we can discuss that further.

A

D

It is mentioned that, as hijacking is a concern for as operators but, for instance, the operators of as3 between two and four. They never articulated what the exact issues are. They experienced from people inadvertently using asp in their uh traffic engineering evidence.

D

F

D

It was pointed out that it's percept reputational damage, maybe there's some operational damage related to monitoring aka, false positives, but as spoofing does exist, it's not clear to me how big of an issue it is.

G

What exists, did you say job? What exists.

D

As high checking does exist, we observe it, but it's not clear to me what the cost to our community is. How big of an issue is it actually.

G

Yeah the nano discussion um has dictated, I mean I don't know if you followed the nano discussion. uh That seems to say that it is a concern if- and it also discussed if as operators have a responsibility to try to prevent as hijacks.

A

Okay, I think we are over time by a little bit. um If I think, if there's more discussion for this or the other topics, we should definitely have that on the list sooner rather than later. So we don't forget, and if there's interest or or need for an interim meeting to talk about this or other topics that would be terrific to hear on the list as.

A

A

And with that I think we'll close the session out. I think we can do that and then whoever is going to be at the grow meeting can just go to the group meeting, which is me so see you in a bit.

A