Re: Intdir telechat review of draft-ietf-httpbis-alias-proxy-status-05

Hi Brian,

Thanks for the clarification! To your two questions:

1. The client shouldn’t be tripped up or confused by seeing non-global names or addresses. These are informational hints, and generally it would be trying to just recognize if the next hop is using a known address or name — an address or name that doesn’t match shouldn’t have any adverse effect.

2. These hints are purely optional for the proxy to send. If it doesn’t deem it appropriate to send the information, it shouldn’t.

Again, for all of these, such informational hints can already be sent — the proxy-status header already lets the next hop IP address or hostname be sent. This document just adds the CNAME chain.

Thanks,
Tommy

> On Oct 23, 2023, at 9:42 AM, Brian Haberman <brian@innovationslab.net> wrote:
> 
> Hi Tommy,
>     Sorry for the brevity in the review. It is quite possible that the deployment scenario I am thinking of is illogical and would be happy to have people tell me these points won't be an issue.
> 
>     The notional scenario I have in mind is one where the proxy is communicating with an external client but a DNS resolver inside of a network.
> 
> Internet          |          Private Networks
>                      |
> Client ----- Proxy ----- DNS resolver
>                      |
> 
> If the DNS results returned to the proxy contain private IP addresses and/or non-global names, does that:
> 
> 1. Lead the client to a state of confusion if it is provided non-global information?
> 
> 2. Expose sensitive information on internal naming/addressing to an external entity?
> 
> Regards,
> Brian
> 
> On 10/23/23 11:43 AM, Tommy Pauly wrote:
>> Hi Brian,
>> Thanks for the review! I’m not sure I quite follow your concern here.
>> This proxy status parameter is a way for the proxy to communicate informational details back to the client about the DNS it performed when communicating to the next hop. Note that it already can communicate the next hop IP address, etc. This helps communicate the CNAME chain, if any exists.
>> The client does not use the next hop IP or CNAME info to make direct connections to the end, but only to understand more about the identity of what was used. I don’t think the proxy sitting behind a NAT or using split DNS is necessarily impactful, but even if the proxy is able to access addresses and DNS resolution that the client could not on its own, it shouldn’t matter.
>> Does this help clarify things? If not, can you further explain what scenario you are concerned with?
>> Best,
>> Tommy
>>> On Oct 23, 2023, at 7:25 AM, Brian Haberman via Datatracker <noreply@ietf.org> wrote:
>>> 
>>> Reviewer: Brian Haberman
>>> Review result: On the Right Track
>>> 
>>> I am an assigned INT directorate reviewer for
>>> draft-ietf-httpbis-alias-proxy-status. These comments were written primarily
>>> for the benefit of the Internet Area Directors. Document editors and
>>> shepherd(s) should treat these comments just like they would treat comments
>>> from any other IETF contributors and resolve them along with any other Last
>>> Call comments that have been received. For more details on the INT Directorate,
>>> see https://datatracker.ietf.org/group/intdir/about/.
>>> 
>>> Major Issues:
>>> 
>>> I am a bit concerned that there is no discussion about the potential scope for
>>> either domain names or IP addresses. What happens if a proxy sits behind a NAT?
>>> Does the NAT now need an ALG to convert private IP addresses to global ones?
>>> What about a situation where the proxy sits behind a firewall utilizing split
>>> DNS?
>>> 
>>>

Received on Monday, 23 October 2023 16:49:49 UTC