Minute IRTF Open Meeting @ IETF-93 Prague, Czech Republic Monday, July 20, 2015 (CEST) 13:00-15:00 Monday Afternoon session I State of the IRTF Lars Eggert 10 min - Opening comments by Lars Eggert (Chair of the IRTF) - IRTF IPR Policy - Administrivia - Discuss list doesn't have a lot of traffic, more is invited - IRTF Open Meeting Agenda IRTF meetings this week This is the most amount of meetings ever held at IETF, this is good. The only group that is not meeting is the delay tolerant networking group Three RGs are in incubation stage, decision is made after one year running. GAIA is not being reviewed at IAB is will be network function virtualization. Not clear if DTNRG will revive, ICCRG is a bit less active than they normally are. Proposed groups are quite active, judging from the lists Since IETF90 IRTF published 5 RFCs Next IETF will be in Yokohama, Internet measurement conference is one week before in Tokyo. IRTF is being interested in bringing in academics, so this is an interesting opportunity to bring business and academia together. This meeting is invite only, but if you're in academia, send in an academic paper and you'll probably get an invite. If you're not an academic, you can send in a position paper. Applied Networking Prize (ANRP) Award Talks 2x 45 min *** Haya Shulman *** for analyzing the deficiencies of DNS privacy approaches: Haya Shulman. Pretty Bad Privacy: Pitfalls of DNS Encryption. ACM Workshop on Privacy in the Electronic Society (WPES), Scottsdale, AZ, USA, November 3, 2014. [Will only take notes of the Q&A] Eliot Lear: How can you avoid the TCP to UDP downgrade? Answer: Downgrade attacks are not specific for DNS, this is critical for the Internet. I can recommend a paper, which designs a basic building block which makes difference between downgrade attacks and connectivity failures When attackers compromise a router, they would be unable to give this capability away, so they can remain undetected. We are making a building block which detects failures on a link vs attacks. We use this by using an anonymity network - won't give the entire paper away. We will be proposing a solution for this, which can also be used for DNS. Stuart Cheshire: Can I point you to another implementation over DNS over TLS? Another small deployment was Apple's Back to my Mac, this was documented in RFC6281 Answer: Happy to receive pointers and more examples. Happy to add that to the study. Stuart: It validates the work you're doing. Allison Mankin of Verisign: This work is great, would like to see more if the TCP work. I would like to mention that a lot of the emphasis is on the difference between the recursive and the authoritative. When you do the recursive ????, it has the opportunity to go to the recursive that it nows has good TCP. This is a different between going through authoritative vs recursive. Answer: This is correct, it doesn't solve the problem on the name server side though. The resolver can go to different instances. Ralf Weber: This reiterates, the DNS is a mess. Would it not be better to make privacy on the underlying protocol and leave this mess. Answer: This is indeed what Versign did. The question is: can you use the standard port or should we go to a different port. I think if you change to TCP currently you will not be able to resolve many domains. We cannot insists on TCP or encryption now, but critically important to continue research in this direction and understand how much work is needed to make this happen and not have detrimental losses. Pre-fetching was looked in with respect to web, and this leaks also a lot. i mention this in the paper, but haven't studied how much it leaks. I used three types of channels: timing/latency, authenticity, (between caching resolver and the name servers). Matthias Wählish: Did you also consider the tail of the Alexa list (not just the first 50k)? Answer: I have a different vantage point with machines from different countries. I report on the 50k because this was the fastest that I manage to finish. I am doing the other trees as well, recurse trees, telephony, IPv4, IPv6. If anyone is interested wants to host this, please let me know. I got some space from MS Azure. Peter Spacek: DNS over Tor Answer: Not a good solution, at the end node you can put spoofed responses. Wolfgang: inbound uses description port, ** & dkg worked on this during Hackathon. Douglas Otis: QUIC runs over UDP Answer: Excellent point, looking into congestion control mechanisms for TCP, that would be suitable for DNS. Would be dependent on whether one would use UDP or pipelines, I am only using TCP, but not against other methods. *** João Luís Sobrinho *** for designing a route-aggregation technique that allows filtering while respecting routing policies: João Luís Sobrinho, Laurent Vanbever, Franck Le and Jennifer Rexford. Distributed Route Aggregation on the Global Network. Proc. ACM CoNEXT, Sydney, Australia, December 2-5, 2014. [Will only annotate Q&A] Stuart Cheshire: There are a lot of smart people and companies working in routing. Why did they not come up with this? Answer: This you should ask them, not me. Dean Bogdanovic: There might be constraints for commercial and technical reasons Carlos from LACNIC: This is really cool. We toyed with similar ideas in the past. I am curious about 2 things: 1. where should we run this in an AS? 2. Within your AS you should keep your specific, the ideal scenario is keeping specifics from customers. Answers: This could also be presented on a router level and see what prefixes are needed there. There might be shorter routes. You cannot filter too much as there may be some stretch, then you lose quality of the routes I would say close to the border, but still need to do research. ** (John from Google?): Difference between this and RFC6769? How much FIB reduction can be achieved? Answer: The filtering results are similar. I assume you realize that one of the challenges that seems to apply here even though your hookup engine optimizes for more specifics, many vendors might not have these concepts. When you get a withdrawal, you need to do more compensation. This could be a large upgrade to BGP for many vendors. Matthias Wählish: This might conflict with security solutions like RPKI . If you include the not secure prefix. Answer: If you gave RPKI you can still be secure and insecure, ** Ken Kalvert, University of Kentucky: I wanted to mention that we did a measurement study, Globecom 2010, how much are we losing, how efficient are current address assignments? We used similar aggregation rules, and our findings are similar, about a factor of 2. Aggregation rules are already there, so you're not adding something to the BGP protocol, is that correct? Answer: You're probably right. I need to make sure I am not creating address space that's not there. Sandy Murphy, Parsons: Is there anything in your work that ensures that the aggregation is minimal, if you have p10 in your p01, p11 example, if the guy is not connected to the p01 customer but if he aggregated p01 and p11 if he is not connected to that address space. Answer: That would break the protocol Sandy: How can you prevent this from happening Answer: The AS should be able to detect this. Sandy: The aggregator should ******* It's not known to the AS who is doing the aggregation there it might not be able to prove its correctness If it does not include all of the sub-prefixes it may end up aggregating routes that cannot be aggregated. [sorry lost connection] Dean Bogdanovic: Thinking about this for the applicability of the Dragon, this could be interesting for intra operators for BGP enabled space. As a single operator you can create some very interesting prefix hierarchies so you can have more efficient hierarchies in your overarching infrastructure. Your limited by the limited FIBs of the devices, the question is how to reduce that. That could be an interesting application. Lars: For more such interesting presentation need to Nominate papers for the APRP for next year.