draft-ietf-intarea-proxy-config

[Michael Welzl]

[ Dragana: in case you’re missing context, please see: https://github.com/mwelzl/oppd  - I’m arranging this side meeting on Thursday ]

Dear OPPD'ers,

Tommy Pauly approached me about our side meeting today and told me about how our “on-path proxy discovery” is potentially related to https://datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/

I wondered about this before and read that draft, but I didn’t immediately understand how it would relate to proxies being on-path. Now I believe it’s like this:

From the Intro:

***

1.A way to fetch PvD Additional Information associated with a known proxy URI (Section 2)

2. A way to list one or more proxy URIs in a PvD, allowing clients to learn about other proxy options given a known proxy (Section 3).

***

I guess method 1 could be used if a proxy is already known, to ask “are you on-path to this destination?”, if such information is added to the PvD "Additional Information". And, method 2 could tell us about new proxies that are on-path.

Is this about right?

In any case, it would be good if others in this list could take a look at this draft so we can have a more informed conversation in the side meeting.

Cheers,

Michael

[Joerg Ott]

Hi Michael,

thanks much  for sharing. I read the draft yesterday but will also have do (at least) one indirection step to understand all of the web configuration ecosystem around Provisioning Domains.

This draft is indeed primary about providing JSON config data for your browser to assist you in deciding which proxy to choose (once you discovered them) and possibly to learn about others.

It may provide useful hints which information a browser would like to obtain before it decides to use a proxy. That is, from our perspective, such information could be needed to decide whether or not to play with an on-path proxy that is discovered on the fly.

It also makes clear the assumption is that browsers operate relative to proxies in the fairly static setting where you got up front time to determine and sort proxy informatio, create an internal “routing table” based upon which proxies can be chosen up front per destination.

Since on-path discovery happens after the INITIAL/SYN packet, however, the routing decision was already taken at that time, so the only bit left is accepting or rejecting an on-path intermediary.

So, there are some pretty interesting learnings here but it seems an orthogonal mechanism. That said, if multiple ways for configuration are available it may be useful in the end to offer compatible information via each — as far as feasible and useful.

Will look further.

Cheers,

Jörg

Sent from my iPad

On 3. Nov 2024, at 23:14, Michael Welzl <mic...@ifi.uio.no> wrote:

[ Dragana: in case you’re missing context, please see: https://github.com/mwelzl/oppd  - I’m arranging this side meeting on Thursday ]

--
https://github.com/mwelzl/oppd
---
You received this message because you are subscribed to the Google Groups "oppd-ietf" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oppd-ietf+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/oppd-ietf/39EA1BC6-502C-4B57-B597-3F1EB65E0705%40ifi.uio.no.

[Michael Welzl]

On Nov 5, 2024, at 7:56 AM, Joerg Ott <o...@in.tum.de> wrote:

Hi Michael,

thanks much  for sharing. I read the draft yesterday but will also have do (at least) one indirection step to understand all of the web configuration ecosystem around Provisioning Domains.

Hooray, I’m not the only one!

Let me openly embarrass myself at this point. When, in section 2, the draft says: "a client issues an HTTP GET request for …”, I wonder: to whom? An already-known proxy, or to the web server?  If it’s the latter, how would a web server have PvD information about my network?  Or if it’s to a proxy, also to get a list of other proxies, then that means that we always need to know at least one proxy as a starting point - right?

This draft is indeed primary about providing JSON config data for your browser to assist you in deciding which proxy to choose (once you discovered them) and possibly to learn about others.

It may provide useful hints which information a browser would like to obtain before it decides to use a proxy. That is, from our perspective, such information could be needed to decide whether or not to play with an on-path proxy that is discovered on the fly.

It also makes clear the assumption is that browsers operate relative to proxies in the fairly static setting where you got up front time to determine and sort proxy informatio, create an internal “routing table” based upon which proxies can be chosen up front per destination.

Since on-path discovery happens after the INITIAL/SYN packet, however, the routing decision was already taken at that time, so the only bit left is accepting or rejecting an on-path intermediary.

So, there are some pretty interesting learnings here but it seems an orthogonal mechanism. That said, if multiple ways for configuration are available it may be useful in the end to offer compatible information via each — as far as feasible and useful.

Will look further.

Cheers,

Jörg

Sent from my iPad

Many thanks for this start!

Cheers,

Michael