Re: RPKI TAs

e.g., https://ripe.net/rpki/tal, https://arin.net/rpki/tal ? obviously, a single TAL would be better but this needs even more rhetoric ... cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

Re: six pages for rov issues

ns. and the view of historic data is also beneficial. cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

Re: Sunday traffic curiosity

hallenges, in particular incentive aspects, have been nicely discussed in "Deployment issues for the IP multicast service and architecture," IEEE Network 2000: https://www.cl.cam.ac.uk/teaching/1314/R02/papers/multicastdeploymentissues.pdf Cheers matthias -- Matthias Waehlisch . F

Re: criterio

er about some (non-hostile or > > worrisome) net activity of criterio autonomous systems. do any friends > > of the family know these folk and could introduce me so i can try to > > learn a bit of ground truth? > > > > thanks. > > > > randy > --

Re: Announcing Peering-LAN prefixes to customers

not sure if anyone ever created one. >   not for AFRINIC, see http://rpki-browser.realmv6.org/ (select AFRINIC, filter for Resource AS0) Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

Re: Spitballing IoT Security

t; > of the World. (Given the current poltical climate, worldwide, this > > should not be a problem, because I lie a lot.) > > > > 2) Second, once elected I will decree that in future all new IoT devices, > > and also all updates to firmware for existing IoT devices will have, > > BUILT IN TO THE KERNEL, code/logic which (a) prevents all outbound TCP > > session initiation and which also (b) strictly rate-limits all other > > protocols to some modest value. > > > > Remember, we're going to have a few billion of these devices online in the > > coming years. If even and modest subset of these can ever be tricked by an > > attacker into spewing non-rate-controlled traffic towards an attacker- > > selected target, then we're gonna have a problem. > > > > > > Regards, > > rfg > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

Re: RPKI and offline routes

Hi, yes. In this context the discussion at IETF92 might be interesting: https://www.ietf.org/proceedings/92/minutes/minutes-92-sidr (search for "Extemporaneous Presentation") Cheers matthias On Tue, 14 Jun 2016, Hugo Slabbert wrote: > > On Mon 2016-Jun-13 17:53:45

Re: RPKI and offline routes

Hi, the creation of a ROA does not require the announcement of the prefix. Creation of a ROA, prefix announcement, and validation of the prefix are decoupled. If you are the legitimate resource holder you can create a ROA for this prefix (even if you don't advertise the prefix). As soon as t

Re: bad announcement taxonomy

innie > > > > Laundered leak? > > how about re-origination? > might be misleading in case you don't re-originate P exactly but only "part of it". What about "origin scrubbing". Cheers matthias -- Matthias Waehlisch . Frei

Re: ARIN's RPKI Relying agreement

> into a small router or two. > which implementation? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

Call for input: RPKI Browser

asking for input at a very early stage. Please let me know which features you would like to see in such kind of tool. Some more details are described here https://labs.ripe.net/Members/waehlisch/call-for-input-rpki-browser Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin

Re: Survey about RPKI/DNSSEC

ymous and should not take more than 5 minutes to commplete. Thanks matthias On Fri, 19 Sep 2014, Matthias Waehlisch wrote: > Hi NANOG, > > we, a group of researchers, try to better understand the deployment of > RPKI and DNSSEC. It's not always easy to find technical

Survey about RPKI/DNSSEC

l post the results to the list. Fell free to contact me offlist in case of further questions or comments. Many thanks! matthias (on behalf of the team) [This email has also been sent to RIPE and SIDR folks.] -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST .

Re: The Next Big Thing: Named-Data Networking

suggesting a NAT-like table in every single router. > And we all know how well NAT boxes scale... > the pending interest table is more similar to multicast routing table, which is maintained by end user subscriptions -- still challenging wrt to scalability. Cheers matthias -- Matthias Waehl

Re: Historical Info

For RIPE there is a new beta service to display history of objects in the RIPE DB https://labs.ripe.net/Members/kranjbar/proposal-to-display-history-of-objects-in-ripe-database Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9

Re: Detection of Rogue Access Points

ill > ring a bell for someone else on the list who does. > do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf ? Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:w

Re: rpki vs. secure dns?

which the ISP starts to create a ROA for a superblock before the customer adds its route prefix into the RPKI ... this happened with AT&T during testing, for example, https://labs.ripe.net/Members/waehlisch/one-day-in-the-life-of-rpki Cheers matthias -- Matthias Waehlisch . Freie U

Re: rpki vs. secure dns?

line 408 ff. in the IETF 83 SIDR minutes * http://www.ietf.org/proceedings/83/minutes/minutes-83-sidr.txt Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org .. http

Re: where was my white knight....

t least a Bachelor student of my got along with them for his thesis. Btw: There is also a very nice overview by Geoff published in Cisco IPJ: * http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html Cheers matthias -- Matthias Waehlisch . Freie Universitaet