Re: [Int-area] New version: draft-pauly-intarea-proxy-config-pvd-02

[Josh Cohen]

Pull request created
https://github.com/tfpauly/privacy-proxy/pull/247


On Tue, Mar 5, 2024 at 1:28 PM Tommy Pauly  wrote:

> Hi Josh,
>
> Yes, the PvD file carries configuration metadata about a network access in
> general, and this extension allows it to carry proxy details. When asking a
> proxy server for its own PvD, that lets it tell you more about which proxy
> protocols it supports and their locations. When asking a network for its
> PvD, that can allow the network to indicate which proxies are associated
> with the network.
>
> With regards to the domain lists, totally agreed that adding exclusion
> sets would be good. That could be easily added as a key!
>
> Best,
> Tommy
>
> On Mar 5, 2024, at 10:23 AM, Josh Cohen  wrote:
>
> Hi Tommy, Dragana,
>
>
> As I'm getting  my head wrapped around this proposal, is it fair to view
> it as a metadata endpoint for a proxy server?  Sort of like a richer
> OPTIONS that doesn’t get forwarded by the proxy?
>
>
> WRT Split DNS:
>
>
> > When present in a PvD Additional Information dictionary that is
> retrieved for a proxy as described in Section 2
> ,
> domains in
> > the dnsZones array indicate specific zones that are accessible using
> the proxy. If a hostname is not included in the
> > enumerated zones, then a client SHOULD assume that the hostname will not
> be accessible through the proxy.
>
>
> This is great.   It is an "inclusion" set, but what about an "exclusion"
> set?   Eg  "use me for everything on the web, except the following internal
> domains"
>
>
> This will be essential for situations where PVD is used as a replacement
> for the JavaScript PAC file, that is discovered through WPAD(NG) or
> elsewhere.
>
>
> With the increasing deployment of IoT devices, they will eventually find
> themselves needing to use a proxy server, especially if they are inside an
> enterprise.
>
>
> Microcontrollers such as Arduino class devices, ESP32 etc, are powerful
> enough to act as web clients and servers.  However, running a JS engine to
> parse the PAC file may require space and computing power that dwarfs that
> for the device functionality itself.  Eg "I am just a temperature sensor!
> Why do I need a JS engine?"
>
>
> On the other hand, there are a plethora of Arduino libraries to parse JSON.
>
>
> WPAD OG was designed 20 years ago in Web dinosaur times. We now have an
> opportunity to have IoT and other devices start off with a more modern,
> efficient and secure format, which hopefully will last us the next 20 years.
>
> Thoughts?
>
> On Fri, Mar 1, 2024 at 9:36 PM Tommy Pauly  40apple@dmarc.ietf.org> wrote:
>
>> Hello INTAREA,
>>
>> At IETF 118, we presented our draft on discovering proxies with PvD
>> information files. We got good support for working on this, along with some
>> feedback for how to improve the format to support more details for the
>> proxies, and more explicit indications of proxy protocols.
>>
>> We’ve just published draft-pauly-intarea-proxy-config-pvd-02 to
>> incorporate this feedback:
>>
>> https://datatracker.ietf.org/doc/draft-pauly-intarea-proxy-config-pvd/
>>
>> https://www.ietf.org/archive/id/draft-pauly-intarea-proxy-config-pvd-02.html
>>
>> We’d like to continue discussing this at the upcoming IETF 119 meeting,
>> and welcome any comments on list!
>>
>> Best,
>> Tommy
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>
>
> --
>
> ---
> *Josh Co*hen
>
>
>
>

-- 

---
*Josh Co*hen
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] New version: draft-pauly-intarea-proxy-config-pvd-02

[Tommy Pauly]

Hi Josh,

Yes, the PvD file carries configuration metadata about a network access in 
general, and this extension allows it to carry proxy details. When asking a 
proxy server for its own PvD, that lets it tell you more about which proxy 
protocols it supports and their locations. When asking a network for its PvD, 
that can allow the network to indicate which proxies are associated with the 
network.

With regards to the domain lists, totally agreed that adding exclusion sets 
would be good. That could be easily added as a key!

Best,
Tommy

> On Mar 5, 2024, at 10:23 AM, Josh Cohen  wrote:
> 
> Hi Tommy, Dragana,
>  
> As I'm getting  my head wrapped around this proposal, is it fair to view it 
> as a metadata endpoint for a proxy server?  Sort of like a richer OPTIONS 
> that doesn’t get forwarded by the proxy?
>  
> WRT Split DNS:
>  
> > When present in a PvD Additional Information dictionary that is retrieved 
> > for a proxy as described in Section 2 
> > ,
> >  domains in
> > the dnsZones array indicate specific zones that are accessible using the 
> > proxy. If a hostname is not included in the
> > enumerated zones, then a client SHOULD assume that the hostname will not be 
> > accessible through the proxy.
>  
> This is great.   It is an "inclusion" set, but what about an "exclusion" set? 
>   Eg  "use me for everything on the web, except the following internal 
> domains"
>  
> This will be essential for situations where PVD is used as a replacement for 
> the JavaScript PAC file, that is discovered through WPAD(NG) or elsewhere.
>  
> With the increasing deployment of IoT devices, they will eventually find 
> themselves needing to use a proxy server, especially if they are inside an 
> enterprise.
>  
> Microcontrollers such as Arduino class devices, ESP32 etc, are powerful 
> enough to act as web clients and servers.  However, running a JS engine to 
> parse the PAC file may require space and computing power that dwarfs that for 
> the device functionality itself.  Eg "I am just a temperature sensor! Why do 
> I need a JS engine?"
>  
> On the other hand, there are a plethora of Arduino libraries to parse JSON.
>  
> WPAD OG was designed 20 years ago in Web dinosaur times. We now have an 
> opportunity to have IoT and other devices start off with a more modern, 
> efficient and secure format, which hopefully will last us the next 20 years.
> 
> Thoughts?
> 
> On Fri, Mar 1, 2024 at 9:36 PM Tommy Pauly  > wrote:
>> Hello INTAREA,
>> 
>> At IETF 118, we presented our draft on discovering proxies with PvD 
>> information files. We got good support for working on this, along with some 
>> feedback for how to improve the format to support more details for the 
>> proxies, and more explicit indications of proxy protocols.
>> 
>> We’ve just published draft-pauly-intarea-proxy-config-pvd-02 to incorporate 
>> this feedback:
>> 
>> https://datatracker.ietf.org/doc/draft-pauly-intarea-proxy-config-pvd/
>> https://www.ietf.org/archive/id/draft-pauly-intarea-proxy-config-pvd-02.html
>> 
>> We’d like to continue discussing this at the upcoming IETF 119 meeting, and 
>> welcome any comments on list!
>> 
>> Best,
>> Tommy
>> ___
>> Int-area mailing list
>> Int-area@ietf.org 
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> --
> ---
> Josh Cohen 
> 
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] New version: draft-pauly-intarea-proxy-config-pvd-02

[Josh Cohen]

Hi Tommy, Dragana,



As I'm getting  my head wrapped around this proposal, is it fair to view it
as a metadata endpoint for a proxy server?  Sort of like a richer OPTIONS
that doesn’t get forwarded by the proxy?



WRT Split DNS:



> When present in a PvD Additional Information dictionary that is retrieved
for a proxy as described in Section 2
,
domains in

> the dnsZones array indicate specific zones that are accessible using the
proxy. If a hostname is not included in the

> enumerated zones, then a client SHOULD assume that the hostname will not
be accessible through the proxy.



This is great.   It is an "inclusion" set, but what about an "exclusion"
set?   Eg  "use me for everything on the web, except the following internal
domains"



This will be essential for situations where PVD is used as a replacement
for the JavaScript PAC file, that is discovered through WPAD(NG) or
elsewhere.



With the increasing deployment of IoT devices, they will eventually find
themselves needing to use a proxy server, especially if they are inside an
enterprise.



Microcontrollers such as Arduino class devices, ESP32 etc, are powerful
enough to act as web clients and servers.  However, running a JS engine to
parse the PAC file may require space and computing power that dwarfs that
for the device functionality itself.  Eg "I am just a temperature sensor!
Why do I need a JS engine?"



On the other hand, there are a plethora of Arduino libraries to parse JSON.



WPAD OG was designed 20 years ago in Web dinosaur times. We now have an
opportunity to have IoT and other devices start off with a more modern,
efficient and secure format, which hopefully will last us the next 20 years.


Thoughts?

On Fri, Mar 1, 2024 at 9:36 PM Tommy Pauly  wrote:

> Hello INTAREA,
>
> At IETF 118, we presented our draft on discovering proxies with PvD
> information files. We got good support for working on this, along with some
> feedback for how to improve the format to support more details for the
> proxies, and more explicit indications of proxy protocols.
>
> We’ve just published draft-pauly-intarea-proxy-config-pvd-02 to
> incorporate this feedback:
>
> https://datatracker.ietf.org/doc/draft-pauly-intarea-proxy-config-pvd/
>
> https://www.ietf.org/archive/id/draft-pauly-intarea-proxy-config-pvd-02.html
>
> We’d like to continue discussing this at the upcoming IETF 119 meeting,
> and welcome any comments on list!
>
> Best,
> Tommy
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>


-- 

---
*Josh Co*hen
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Tom Herbert]

On Tue, Mar 5, 2024 at 8:56 AM Toerless Eckert  wrote:
>
> On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:
> > We can treat them as EH for purposes of extension header ordering in
> > section 2.2. Also, IPv4 AH needs to be updated to take EH into account
> > as mentioned below. Other than that I don't believe there are any
> > substantive differences.
>
> Yes, i am trying to use ESP/AH as examples to understand the benefits
> of destination headers as opposed to just non-extension headers ..
>
> > No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel
> > changes to Linux will be straightforward.
>
> My question was not about differences in API between IPv4/IPv6, but between 
> when
> ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they become
> extension because the kernel changes have been applied.
>
> Ul;timately, i am trying to understand whether, and if so WHY we should
> reclassify ESP and AH in IPv4 to be extension headers. Right now the only
> argument i would know would be "consistency with IPv6", but that by itself
> does not seem to be sufficient to change something for what's being deployed
> worldwide in so many places. So there should be a technical benefit.
>
> And if the answer is "it does not make any difference whatsoever", then i also
> wonder why we would want to do it...

Hi Toerless,

Because there is no solution in IPv4 to carry ancillary data in
packets, and we are seeing proposals being made for new protocols that
eschew use of extension headers even for IPv6 use cases on the basis
that EH isn't supported in IPv4. If IPv6 had achieved ubiquitous
deployment then I'd agree that IPv4 EH wouldn't be needed, but IPv6 is
not there yet particularly in enterprise networks. Until IPv6 reaches
ubiquity, which could still be years away, there is a gap in features
in IPv4 that is turning into a liability for IETF.

An example workaround for IPv4 not having EH is draft-ravi-ippm-csig.
This is a proposal to put E2E network layer information into L2 (which
I consider a hack because L2 layer information is not routable
end-to-end without assuming some proprietary switch support). HBH
Options is designed precisely to carry the signaling described in
draft-ravi-ippm-csig, however the authors stated that they don't want
to use HBH because it is not supported in IPv4 and no IPv4 support is
a showstopper for them.

Another example is SPUD which would allow ancillary information in UDP
with a shim header in UDP. UDP is supported in IPv4 and IPv6 and this
scheme works up to the point that we want network devices to read the
information from UDP payloads which might lead to incorrectness. If a
network device were to write into UDP payload to modify data inflight,
then the protocol is fundamentally not robust.

That being said, use of the Fragment header would be a technical
improvement over IPv4 fragmentation (ID field is larger).

>
> > > Any other functional differences ? Aka: i couldn't find a simple:
> > >
> > > "If i want to define a new protocol header, should i call it an
> > >  extension header or an ipv6 extension header - for Dummies" ?
> >
> > I think there are IPv6 extension headers and IPv4 extension headers.
> > IPv4 extension headers are probably just a subset of IPv6 extension
> > headers.
>
> That's certainly safer, e.g.: asking for a separate column in the IANA 
> registry.
>
> > > be renamed to "IP/IPv6 Extension Header". But when this was done
> > > to AH/ESP, and there actually is a functional difference expressed by
> > > this extension header (as opposed to non-extension header) status, then
> > > what be the imapct of this ? Aka: I upgrade my linux kernel to extension
> > > header and all my AH/ESP breaks ?  Or i do get the benefit of above
> > > (userland access) ?
> > >
> > > Would there be any (backward compatibility) reason to have new codepoints 
> > > in IPv4 for ESP/AH
> > > with this extension header status and leave the existing (non extension
> > > header) codepoints alone ?
> >
> > No, I don't think we need that. ESP/AH should be backwards compatible.
> > For instance, if someone sends AH with HBH in IPv4 then they know that
> > their using EH and AH would take into account mutable HBH options. If
> > the packet is sent to a host that supports IPv4 EH then they would
> > know how to process the AH with HBH correctly. If the packet is sent
> > to a legacy node that doesn't support EH, then the packet will bv
> > dropped since the host doesn't recognize protocol 0 (HBH).
>
> Not clear. What you are writing implies that the encoding on the wire would
> change for AH from what it is now. What's exactly the change ? It's not
> in the next header field...

There is no change to AH protocol format. We just need to describe how
IPv4 AH works in the presence of extension headers.

>
> > There is no
> > behavioral change at either the receiver or the sender if someone
> > sends an AH with no other EH. The draft will need to update 

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Toerless Eckert]

On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:
> We can treat them as EH for purposes of extension header ordering in
> section 2.2. Also, IPv4 AH needs to be updated to take EH into account
> as mentioned below. Other than that I don't believe there are any
> substantive differences.

Yes, i am trying to use ESP/AH as examples to understand the benefits
of destination headers as opposed to just non-extension headers ..

> No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel
> changes to Linux will be straightforward.

My question was not about differences in API between IPv4/IPv6, but between when
ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they become
extension because the kernel changes have been applied.

Ul;timately, i am trying to understand whether, and if so WHY we should
reclassify ESP and AH in IPv4 to be extension headers. Right now the only
argument i would know would be "consistency with IPv6", but that by itself
does not seem to be sufficient to change something for what's being deployed
worldwide in so many places. So there should be a technical benefit.

And if the answer is "it does not make any difference whatsoever", then i also
wonder why we would want to do it...

> > Any other functional differences ? Aka: i couldn't find a simple:
> >
> > "If i want to define a new protocol header, should i call it an
> >  extension header or an ipv6 extension header - for Dummies" ?
> 
> I think there are IPv6 extension headers and IPv4 extension headers.
> IPv4 extension headers are probably just a subset of IPv6 extension
> headers.

That's certainly safer, e.g.: asking for a separate column in the IANA registry.

> > be renamed to "IP/IPv6 Extension Header". But when this was done
> > to AH/ESP, and there actually is a functional difference expressed by
> > this extension header (as opposed to non-extension header) status, then
> > what be the imapct of this ? Aka: I upgrade my linux kernel to extension
> > header and all my AH/ESP breaks ?  Or i do get the benefit of above
> > (userland access) ?
> >
> > Would there be any (backward compatibility) reason to have new codepoints 
> > in IPv4 for ESP/AH
> > with this extension header status and leave the existing (non extension
> > header) codepoints alone ?
> 
> No, I don't think we need that. ESP/AH should be backwards compatible.
> For instance, if someone sends AH with HBH in IPv4 then they know that
> their using EH and AH would take into account mutable HBH options. If
> the packet is sent to a host that supports IPv4 EH then they would
> know how to process the AH with HBH correctly. If the packet is sent
> to a legacy node that doesn't support EH, then the packet will bv
> dropped since the host doesn't recognize protocol 0 (HBH).

Not clear. What you are writing implies that the encoding on the wire would
change for AH from what it is now. What's exactly the change ? It's not
in the next header field...

> There is no
> behavioral change at either the receiver or the sender if someone
> sends an AH with no other EH. The draft will need to update RFC4302 to
> describe AH processing with IPv4 EH present.
> 
> RFC4303 needs an update as well, but that's just to say that EH after
> the ESP is covered by the encryption, but I don't believe that
> materially changes the requirements.

I guess unless i can get excited for AH/ESP to get some improved behavior
when turning into extension headers (see Q above), i'd probably stick to not 
touching
them, aka: do not declare them to be extension headers for IPv4.

Cheers
Toerless

> Tom
> 
> >
> > Cheers
> > Toerless
> >
> > On Thu, Feb 22, 2024 at 05:40:31PM -0800, Tom Herbert wrote:
> > > Hi,
> > >
> > > I updated the IPv4 extension headers draft. I structured it to be
> > > self-contained without any normative references for IPv6 RFCs. It's a
> > > little bigger, but about 80% of the text is cut-and-paste from other
> > > RFCs and drafts.
> > >
> > > Comments are appreciated!
> > >
> > > Tom
> > >
> > > -- Forwarded message -
> > > From: 
> > > Date: Thu, Feb 22, 2024 at 5:29 PM
> > > Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt
> > > To: Tom Herbert 
> > >
> > >
> > > A new version of Internet-Draft draft-herbert-ipv4-eh-03.txt has been
> > > successfully submitted by Tom Herbert and posted to the
> > > IETF repository.
> > >
> > > Name: draft-herbert-ipv4-eh
> > > Revision: 03
> > > Title:IPv4 Extension Headers and Flow Label
> > > Date: 2024-02-23
> > > Group:Individual Submission
> > > Pages:47
> > > URL:  https://www.ietf.org/archive/id/draft-herbert-ipv4-eh-03.txt
> > > Status:   https://datatracker.ietf.org/doc/draft-herbert-ipv4-eh/
> > > HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-eh
> > > Diff: 
> > > https://author-tools.ietf.org/iddiff?url2=draft-herbert-ipv4-eh-03
> > >
> > > Abstract:
> > >
> > >This specification defines extension