[{"author": "Anthony Somerset", "text": "

Aijun please disable your camera and allow Dan Li to put his camera on if possible?

", "time": "2022-07-25T19:08:40Z"}, {"author": "Rob Austein", "text": "

It is apparently not possible to find a volume level where Joel is audible and other speakers don't blow me into the next room.

", "time": "2022-07-25T19:08:44Z"}, {"author": "Jeffrey Haas", "text": "

We can see you

", "time": "2022-07-25T19:09:11Z"}, {"author": "Joel Halpern", "text": "

Can other remote folks please confirm that they are having trouble hearing me (in the sparse occasions when I need to say something.) It may be that when we got the in-room volume fixed, we created other problems.

", "time": "2022-07-25T19:10:07Z"}, {"author": "Tony Li", "text": "

@Joel You continue to be about 6db down.

", "time": "2022-07-25T19:10:28Z"}, {"author": "Joel Halpern", "text": "

Thanks. I will try to come as close as I can to swallowing the microphone.

", "time": "2022-07-25T19:10:57Z"}, {"author": "Tony Li", "text": "

I suspect that this has more to do with the local mixer than anything else.

", "time": "2022-07-25T19:11:31Z"}, {"author": "\u00c9ric Vyncke", "text": "

Ask meetecho ?

", "time": "2022-07-25T19:12:00Z"}, {"author": "Lorenzo Miniero", "text": "

The suggestion is indeed to speak closer to the mic for chairs

", "time": "2022-07-25T19:12:36Z"}, {"author": "Joel Halpern", "text": "

The odd part on my volume is that we confirmed that the back of the room can hear me. But apparently, I am softer remote.

", "time": "2022-07-25T19:12:51Z"}, {"author": "Joel Halpern", "text": "

@meetecho? remtoe audio check?

", "time": "2022-07-25T19:13:10Z"}, {"author": "Lorenzo Miniero", "text": "

If the comparison is with remote speakers, their volume may indeed be higher than what comes from the room

", "time": "2022-07-25T19:13:50Z"}, {"author": "Tony Li", "text": "

Been there, done that. Where's Radia?

", "time": "2022-07-25T19:18:23Z"}, {"author": "Joel Halpern", "text": "

@Tony in Constantinople, right?

", "time": "2022-07-25T19:19:22Z"}, {"author": "Daniam Henriques", "text": "

Compromised routers would be capable of doing far more evil than sending some spoofed data packets out of the network. I agree with Jared.

", "time": "2022-07-25T19:19:32Z"}, {"author": "Antoin Verschuren", "text": "

There are examples of networks where due to diversity of network elements, some older routers do not support level-3 filtering...

", "time": "2022-07-25T19:28:46Z"}, {"author": "Antoin Verschuren", "text": "

I meany layer-3 filtering ;-)

", "time": "2022-07-25T19:29:27Z"}, {"author": "Jeffrey Haas", "text": "

@tony li Where the presentations will eventually be heading is permitting filtering to be done on a proxy basis in places where routing state isn't sufficient to let you do urpf type filters. Still not a perfect solution.

", "time": "2022-07-25T19:31:12Z"}, {"author": "Antoine Fressancourt", "text": "

Antoin Verschuren said:

\n
\n

There are examples of networks where due to diversity of network elements, some older routers do not support level-3 filtering...

\n
\n

Those routers are for sure power hogs, You might be able to fund their replacement from the electricity you will save (and DC real estate costs)

", "time": "2022-07-25T19:31:44Z"}, {"author": "Daniam Henriques", "text": "

@Antoin, not to mention variable CAM space based on different platforms.

", "time": "2022-07-25T19:31:48Z"}, {"author": "Antoin Verschuren", "text": "

Just saying it's a viable gap, the solutions to me are clear ;-)

", "time": "2022-07-25T19:33:22Z"}, {"author": "Antoin Verschuren", "text": "

But it would be cool if we find solutions where Router 5 in this example could identify and block this .

", "time": "2022-07-25T19:34:19Z"}, {"author": "Tony Li", "text": "

I'd suggest that deployment be part of the problem statement.

", "time": "2022-07-25T19:34:55Z"}, {"author": "Jeffrey Haas", "text": "

^

", "time": "2022-07-25T19:37:50Z"}, {"author": "Tony Li", "text": "

I'd suggest that the technical requirements be simplified: filter access links, filter at area boundaries.

", "time": "2022-07-25T19:40:26Z"}, {"author": "Jeffrey Haas", "text": "

If I'm not mangling the terminology, also discovery of the convex domain of devices where a consistent filtering policy can be enforced.

", "time": "2022-07-25T19:42:11Z"}, {"author": "Anthony Somerset", "text": "

I think the source prefix would have to be learned by some routing protocol

", "time": "2022-07-25T19:44:22Z"}, {"author": "Lin Han", "text": "

I think if the end-host are compromised, this protocol cannot distinguish it, and the solution should be in upper layer, not in network layer

", "time": "2022-07-25T19:45:35Z"}, {"author": "Tony Li", "text": "

I'm confused. Why isn't the management plane the source of truth about addressing?

", "time": "2022-07-25T19:46:00Z"}, {"author": "Mingqing Huang", "text": "

SAV learning might not be end-host triggered

", "time": "2022-07-25T19:46:11Z"}, {"author": "Tony Li", "text": "

Are we depending on the Evil Bit?

", "time": "2022-07-25T19:47:14Z"}, {"author": "Igor Lubashev", "text": "

I think what was proposed is a new management protocol for populating SAV tables

", "time": "2022-07-25T19:47:22Z"}, {"author": "\u00c9ric Vyncke", "text": "

@tony no E-bit in IPv6 :-(

", "time": "2022-07-25T19:47:44Z"}, {"author": "Tony Li", "text": "

Care to collaborate on the RFC for that? :)

", "time": "2022-07-25T19:48:19Z"}, {"author": "Jen Linkova", "text": "

@Eric: We can create an EH for that!

", "time": "2022-07-25T19:48:21Z"}, {"author": "\u00c9ric Vyncke", "text": "

@tony & jen: good ideas ! ;-)

", "time": "2022-07-25T19:48:39Z"}, {"author": "Anthony Somerset", "text": "

is there a typo on the slide? BCP84 referred to as RFC3704 and 8704?

", "time": "2022-07-25T19:48:53Z"}, {"author": "Jeffrey Haas", "text": "

https://tools.ietf.org/search/bcp84

", "time": "2022-07-25T19:49:39Z"}, {"author": "Igor Lubashev", "text": "

@Anthony Somerset That's what RFC states.

", "time": "2022-07-25T19:49:44Z"}, {"author": "Jeffrey Haas", "text": "

better: https://www.rfc-editor.org/info/bcp84

", "time": "2022-07-25T19:50:05Z"}, {"author": "Joel Halpern", "text": "

@Anthony, a BCP number can refer to a collection of RFCs.

", "time": "2022-07-25T19:50:24Z"}, {"author": "Anthony Somerset", "text": "

thanks

", "time": "2022-07-25T19:50:25Z"}, {"author": "Igor Lubashev", "text": "

Both RFCs claim to be BCP-84 on their datatracker: https://datatracker.ietf.org/doc/html/rfc8704

", "time": "2022-07-25T19:50:39Z"}, {"author": "Joel Halpern", "text": "

@Igor and they are both part of BCP 84.

", "time": "2022-07-25T19:50:54Z"}, {"author": "Jeffrey Haas", "text": "

A BCP is allowed to include more than one rfc.

", "time": "2022-07-25T19:51:02Z"}, {"author": "Tony Li", "text": "

I have learned something today. :)

", "time": "2022-07-25T19:51:49Z"}, {"author": "Anthony Somerset", "text": "

me too

", "time": "2022-07-25T19:52:25Z"}, {"author": "Antoin Verschuren", "text": "

The problem is that AS4 can nevel learn that AS1 is in it's customers cone...

", "time": "2022-07-25T20:00:54Z"}, {"author": "Jeffrey Haas", "text": "

couldn't learn it... in routing.

", "time": "2022-07-25T20:03:56Z"}, {"author": "Antoin Verschuren", "text": "

correct

", "time": "2022-07-25T20:04:08Z"}, {"author": "Jeffrey Haas", "text": "

where this discussion eventually goes is that it is necessary to seed sav filtering from sources outside of routing.

", "time": "2022-07-25T20:04:20Z"}, {"author": "Jeffrey Haas", "text": "

for example, from an aspa graph

", "time": "2022-07-25T20:04:34Z"}, {"author": "Jeffrey Haas", "text": "

and even that won't be sufficient in some circumstances, I think

", "time": "2022-07-25T20:05:00Z"}, {"author": "Antoin Verschuren", "text": "

or from external database data like IRRs ROAs, ....attestation..

", "time": "2022-07-25T20:05:18Z"}, {"author": "Jeffrey Haas", "text": "

The nice part of seeding sav from rpki is that you at least have some level of security. Whether the rpki security model is something that makes people happen with forwarding or sav security will be part of the discussion

", "time": "2022-07-25T20:06:11Z"}, {"author": "Joel Halpern", "text": "

Assuming we get there, we will hear about the ASPA option in a little bit.

", "time": "2022-07-25T20:06:16Z"}, {"author": "Anthony Somerset", "text": "

How is Gap 3 different from the improper permit gap 1?

", "time": "2022-07-25T20:11:37Z"}, {"author": "Tony Li", "text": "

A wee bit more distance from the mike, please.

", "time": "2022-07-25T20:19:57Z"}, {"author": "Tony Li", "text": "

Much better, thank you.

", "time": "2022-07-25T20:20:34Z"}, {"author": "Jeffrey Haas", "text": "

the casual roa comment was my fault. :-)

", "time": "2022-07-25T20:21:34Z"}, {"author": "Michael Hollyman", "text": "

Just need spoofed traffic to follow https://www.ietf.org/rfc/rfc3514.txt :smiley:

", "time": "2022-07-25T20:23:21Z"}, {"author": "Jeffrey Haas", "text": "

or could be the option that was cited in the rfc - burns more fib space to do the work.

", "time": "2022-07-25T20:25:40Z"}, {"author": "Tony Li", "text": "

Hypothesis: lacking automated configuration, most ISPs are unwilling to manage explicit filtering.

", "time": "2022-07-25T20:26:55Z"}, {"author": "Jeffrey Haas", "text": "

^

", "time": "2022-07-25T20:27:46Z"}, {"author": "Antoin Verschuren", "text": "

Question to relay in the mic: Why isn't learning prefixes from accurate IRR data included in the BAR-SAV method? As we have seen in the GAP analisys, BGP update messages will not see paths with no-exports in the customer ASN, so the calculation of the customers cone will not be complete when only ingesting BGP udates from your customer.

", "time": "2022-07-25T20:28:09Z"}, {"author": "Jeffrey Haas", "text": "

IRR could work as well... if it weren't full of crap.

", "time": "2022-07-25T20:28:37Z"}, {"author": "Jeffrey Haas", "text": "

It'd have to be a curated IRR.

", "time": "2022-07-25T20:28:46Z"}, {"author": "Joel Halpern", "text": "

@Antoin - I will relay the quesiton when he finishes this slide.

", "time": "2022-07-25T20:28:47Z"}, {"author": "Antoin Verschuren", "text": "

then require customers to clean up crappy IRR data if they want their packets to reach destinations ;-)

", "time": "2022-07-25T20:30:17Z"}, {"author": "Doug Montgomery", "text": "

Authenticated IRRs could also be a source.

", "time": "2022-07-25T20:30:17Z"}, {"author": "Kotikalapudi Sriram", "text": "

Agree with Doug's comments

", "time": "2022-07-25T20:31:14Z"}, {"author": "Antoin Verschuren", "text": "

yes, but that is basically what ROAs will do. IRRR data is your intend to route packets.

", "time": "2022-07-25T20:32:03Z"}, {"author": "Antoin Verschuren", "text": "

And to know what ASNs your customers accepts prefixes from

", "time": "2022-07-25T20:32:44Z"}, {"author": "Anthony Somerset", "text": "

my concern in the solution space to take note would be compute impact of bar-sav - but so far it makes most overall sense to me if we get over the validation issues noted

", "time": "2022-07-25T20:37:43Z"}, {"author": "Lancheng Qin", "text": "

It seems that BAR still conditionally works if some ASes do not deploy roa or aspa

", "time": "2022-07-25T20:38:01Z"}, {"author": "Jeffrey Haas", "text": "

It can be possible to use stale data in rpki if it validated at one point to mitigate the point Ben raised. Not greatest idea but addressing the fragility of the graph would be needed.

", "time": "2022-07-25T20:38:10Z"}, {"author": "Anthony Somerset", "text": "

@Joel Halpern wouldn't want to waste time talking about solutions ahead of time

", "time": "2022-07-25T20:38:36Z"}, {"author": "Lancheng Qin", "text": "

But if ASes in the customer cone do not deploy roa or aspa, there may be some problems

", "time": "2022-07-25T20:42:38Z"}, {"author": "Tony Li", "text": "

Well, the good news is that RPKI does seem to be making deployment progress.

", "time": "2022-07-25T20:43:10Z"}, {"author": "Tony Li", "text": "

https://rpki-monitor.antd.nist.gov/

", "time": "2022-07-25T20:44:02Z"}, {"author": "Kotikalapudi Sriram", "text": "

yes, BAR-SAV improves on rfc 8704 just with BGP and then it does more/better if ROA and (later) ASPA are available

", "time": "2022-07-25T20:44:58Z"}, {"author": "Mingqing Huang", "text": "

the way to address DSR scenario requires new roa record, which might not align with current roa mechanism

", "time": "2022-07-25T20:47:50Z"}, {"author": "Kotikalapudi Sriram", "text": "

no, it does not require a new type of ROA.

", "time": "2022-07-25T20:50:18Z"}, {"author": "Mingqing Huang", "text": "

not a new type of format, I mean which not align to actual route annouced

", "time": "2022-07-25T20:51:26Z"}, {"author": "Mingqing Huang", "text": "

it might requires to update ROA rfc etc.

", "time": "2022-07-25T20:52:03Z"}, {"author": "Igor Lubashev", "text": "

@Mingqing Huang As I said, BAR-SAV is kind of a hack (as is the entire BCP-84) in that it is using signals not developed for the purpose. It would be \"cleaner\" to have a ROA type specifically developed for SAV. But it is not required, and requiring it would violate the requirement of ensuring ease of adoption (since now things have to change \"on the wire\").

", "time": "2022-07-25T20:52:39Z"}, {"author": "Kotikalapudi Sriram", "text": "

Mingqing - AS registers ROA for the prefixes it owns irrespective of whether they are announced. RPKI allows that -- not an issue

", "time": "2022-07-25T20:53:20Z"}, {"author": "Mingqing Huang", "text": "

thanks, Sriram:)

", "time": "2022-07-25T20:54:32Z"}, {"author": "Daniam Henriques", "text": "

Saving comments regarding labelled switched traffic, load sharing and FRR (filtering in sync with rapid changes in path) for later once the problem space is better defined.

", "time": "2022-07-25T20:57:00Z"}]