Re: [Last-Call] [Masque] Opsdir last call review of draft-ietf-masque-connect-ip-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Note that this document enables IP proxying over HTTP, which is part of the deliverables detailed in the MASQUE WG charter. 

The time to raise concerns about whether IP proxying over HTTP is useful would have been during the BoF or chartering. As it stands, the charter was signed off by the IESG. The WG has spent considerable effort building consensus and running code to deliver what we were tasked with.

Cheers
Lucas
Speaking as a MASQUE enthusiast

On Mon, 10 Apr 2023, 22:40 David Schinazi, <dschinazi.ietf@xxxxxxxxx> wrote:
Hi Linda,

The examples of IP tunnels that you mention do not work through HTTP load balancers. We have scenarios where that is required, so I'll have to respectfully disagree with you as to whether this "makes sense" or not.

David

On Mon, Apr 10, 2023 at 2:36 PM Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> wrote:

David,

 

You can build IP layer tunnels much easier. If the two peers have been authenticated, you don’t need IKEv2 nor IPsec. You can use simple GRE IP tunnel (or IPinIP, NVGRE, GEVENE, VXLAN,  etc.) with HMAC encryption.

 

HTTP is built on top of IP layer. It doesn’t make sense to add IP tunnel on top of HTTP.

 

Linda

 

From: David Schinazi <dschinazi.ietf@xxxxxxxxx>
Sent: Wednesday, March 22, 2023 7:08 PM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-masque-connect-ip.all@xxxxxxxx; last-call@xxxxxxxx; masque@xxxxxxxx; Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Subject: Re: Opsdir last call review of draft-ietf-masque-connect-ip-08

 

Hi Linda,

 

Thank you very much for your review. I'm worried you might have misunderstood what this document is about. We're not trying to change how the Internet operates or how to run BGP. We're building an IP tunnel. A previous example of such a tunnel is IKEv2/IPsec. Tunneling provides amongst other things confidentiality guarantees that are not provided by the IP layer. Since this is a tunnel, it needs a way to share internal IP addresses, and to share what routes can be reached through the tunnel.

 

I hope this helps,

David

 

On Wed, Mar 22, 2023 at 4:59 PM Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Linda Dunbar
Review result: Serious Issues

Reviewer: Linda Dunbar
Review result: Has Issues

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

Summary:
This document describes the method to encode IP packets with the HTTP frame.

Issue-1: HTTP frame itself is carried by an IP packet. If a client needs to
send data packets to its desired destinations (e.g., IP D, E, ) via the node
that acts as the IP Proxy shown in Figure 14, it can be much easier
accomplished by establishing an IP tunnel between the Client and the "IP Proxy
Node (i.e., the tunnel between IP-A and IP-B). The IP layer can already achieve
this goal natively. You don't need to put an IP packet inside an HTTP frame
which is a payload to an IP packet.

Issue-2: Address request capsule:
In order for the Client HTTP frame to reach the Proxy node, they both already
have the IP connection. What is the purpose of the Address request?

Issue-3: Section 4.7.3 Route_advertisement Capsule:
The widely deployed BGP can advertise the routes. You don't need another layer
to repeat the work.

Best Regards,
Linda Dunbar

--
Masque mailing list
Masque@xxxxxxxx
https://www.ietf.org/mailman/listinfo/masque
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux