IRTF maprg agenda for IETF-117 (San Francisco)

• Date: Friday, 28 July 2023, Session I 0930-1130
• Room: Continental 6
• Chairs Mirja and Dave
• Notes: Gorry Fairhurst

Overview and Status - Mirja/Dave

Notewell and other anouncements (see slides).

Internet Scale Reverse Traceroute - Kevin Vermeulen (remote)

Tim Chown: I understand the RR option is IPv4.
Kevin: We don't have a solution for IPv6.

Gorry Fairhurst: What is the transport - I know transport headers can
influence ECMP...
Kevin: We measured ICMP traffic at the moment.

Ben Schwartz: Are there any changes you think the IETF could help with?

Kevin: I saw an ID on reverse traceroute (using a new ICMP type), which
might be useful if this progresses.

Tim: Many paths are asymmetric, how many?
Kevin: 47% are asymmetric at the AS level.

Web Privacy By Design: Evaluating Cross-layer Interactions of QUIC, DNS and H/3 - Jayasree Sengupta (remote)

Ben Schwartz: I think you may be using the term "DoQ" differently to
what is often used in the IETF. Is DoH3 the same as DoQ+H3?
Jayasree: No this tries to serve the DNS and content from the same
sever, using the same QUIC connection.
Ben: I think that sounds like DoH3 - that isn't what is thought of in
the IETF as DoQ (where the protocol stack is different).
Ben: Why would the DNS server be co-located with content?
Jayasree: In the future we think the CDN could be the same in the
future.
Ben: If I do not know the content IP address, then you'll need a new
connection. I recommend looking in Chromium, and look at the way this
separates DNS and web page retrivel in the client for privacy reasons.

Mike Bishop: It would be good to clarify the things Ben mentioned.
Jayasree: Yes, we'd like to see DNS and content on the same connection.

Mike: How do decide to talk to the server in the first place?
Jayasree: For our epxeriment, we feed in the IP address. This is a
future-looking idea based on the CDN has DNS functions.

Spencer Dawkins: Thanks for working on this. I think the same type of
questions might apply to MoQ etc.

Eric Kinear: Thanks also. We did have a document that allowed a resolver
to be specified for a particular domain (with authority) that can be
more closely with that content, and that seems like it might apply here.

Exploring the Cookieverse: A Multi-Perspective Analysis of Web Cookies - Ali Rasaii (remote)

Dave: Thanks for your talk, let's use email and the chat for questions.

User Awareness and Behaviors Concerning Encrypted DNS Settings in Web Browsers - Ranya Sharma (remote)

Ted Hardie: Thanks for bringing this interesting work here. Did you do
random assignments and people who selected non-default browsers (who may
be more security aware).
Ranya: This was when we used randomised browsers, to spread the number
of people per browser used.
Ted: Did you use a script?
Ranya: We did, we did not look at what happened when you presented this.
most would benefit from more information that is easy to access.

Ben: I think the Chromium interface tries to follow this recommendation.
The answer could be very different in different scenarios, such as in
Indonesia where they have different security expectations.

Wes Hardaker: Did you ask about whether they had different views about
whether their data was given to an ISP (mobile or other)?
Ranya: Yes, have a look at our paper which has expecations for small
companies vs. ISPs.

IPvSeeYou: Exploiting Leaked Identifiers in IPv6 for Street-Level Geolocation - Robert Beverly (remote)

Bob Hinden: This is important as the IETF has tried to deprecate this,
and the vast majority of devices use the randomised values. I see that
ISP devices still need to fix this.
Robert: I agree it has been known as a problem for a long time. There is
a really long-tail relating to deployed devices, 100's millions of
devices continue to use this in the wild and have still to be updated.

Rui Paulo: How do you determine the accuracy of the data at the street
level?
Robert: We started with known contacts, and then partnered with new a
national body.

Tim Chown: The RFC doesn't say "MUST NOT" use the MAC address- but does
say they SHOULD NOT do this, of course not all vendors adhere to the
IETF recommendations.

Measurement Lab: Supporting Open Internet Research - Lai Yi Ohlsen (remote)

Ali Rezaki: There is work on environmental impact work at the IETF. Have
you any related work?
Lai Yi: No, but there is a lot more that our platform can do, and this
may be interesting to do.

Francois Nguyen: Do you have people in Russia, China and some other
places?
Lai Yi: Not at the moment, talk to us.
Francois: Where is the data stored is there a GDPR issue?
Lai Yi: see our web site.