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
