Re: [Masque] draft-ietf-masque-connect-ethernet-06 early Httpdir review

Hi Martin,

some comments/questions below. Marked with [MK].

On 14.05.25, 07:32, "Martin Thomson via Datatracker" <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:


Document: draft-ietf-masque-connect-ethernet
Title: Proxying Ethernet in HTTP
Reviewer: Martin Thomson
Review result: Ready with Issues


This document defines a means to negotiate an Ethernet tunneling protocol that
runs over HTTP, like other MASQUE proposals, just one (specific) layer down
from the (old) "waist" of the Internet [1].


The issues here are pretty minor. I don't like well-known URIs for this use
case, and think that they are unnecessary here. (I don't understand the sort
of special cachet they seem to have.) The security considerations are a bit
too lean for something shaped like this and could use some more work.


# Issues


Section 3 defines the use of a URI template. I see two problems, one
mechanical, one foundational.


The mechanical one is that the encoding for the VLAN identifier is not
specified. If this were to be useful for interoperation, that would need to be
specified. I'd assume a decimal encoding, but three hex digits also makes a
bunch of sense for this one.


But that leads to the real problem: the meaning of a VLAN only has value to a
network administrator. While it might make sense to target a specific VLAN,
the exact semantics of the identifier - or lack thereof - needs to be
communicated out of band. We don't have any protocol for that.

[MK] Section 9.2 (https://www.ietf.org/archive/id/draft-ietf-masque-connect-ethernet-06.html#name-ieee-8021q-vlan-tagging) recommends to bleach the VLAN tags from the client and let the proxy apply its own tagging. However, more generally we discussed VLAN tagging in issue #15 (https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ethernet/issues/15) and decided to not address VLAN tagging further by e.g. providing a tag but rely on the proxy configuration. Or do you have a specific use case in mind where explicit signalling is absolutely needed?


I don't think that the /.well-known/ prefix is justified in this context.
Well-known resources exist to simplify configuration, so that clients can
supply a domain name (and port), rather than a URL. But this is a prime
example where supplying a complete URL is ideal. It's still a string, and
clearly distinct from a domain name, so it's not out of the question to just
overload input fields in configuration interfaces.

[MK] We wanted to align this with connect-ip and connect-udp. Maybe it's not absolutely necessary for ethernet, but do you think it's a problem to have it?


What happens if there are multiple proxies on the same segment and their
clients use the same MAC address? That's possible if it is the same client
connecting to two proxies.

[MK] I guess the same that happens if you manually config to devices with the same MAC address. This is a configuration error in my point of view. So I guess for connect-ethernet that means you can only use one proxy at a time and that's probably something we should document in the draft. Thanks, good point!


Presumably there are protocols that run over Ethernet involved. Does this
design depend on a gateway (i.e., the entity sending RAs) being on the
proxy-side of the network? Can a client act in that role? I see no reason why
not. Are there things that need to be taken into account when you have a
gateway that might disappear due to connectivity issues? Section 10 talks
about poisoning neighbor discovery state ("hi, your router is no longer a
router") but that discussion is pretty lightweight. It seems like this could
be more thorough. For instance, under what circumstances would a proxy accept
and send frames with a source MAC that it has received, not sent? (This talks
about "falsified" source MACs, but what does that even mean with Ethernet
anyway?)

The document explicitly disclaims any of this, but I don't think that is a good
idea. This is something that any implementation needs to deal with. Even if
the default posture was to accept just one, previously-unused source MAC, only
opening up to more with extra conditions, that would go a long way to making
this secure. YOLO doesn't seem like a great plan for something like this,
because it is unlikely that real deployments will accept that sort of thing.

[MK] We mostly decided to not specify any ethernet specific handling. The proxy needs to act as an Ethernet bridge but we didn't identify a use case where any special handling is required on the proxy layer. This is noted in section 7 (https://www.ietf.org/archive/id/draft-ietf-masque-connect-ethernet-06.html#name-ethernet-frame-handling). Or do you think there is anything that needs specific handling in the proxy beyond what you would do in an Ethernet bridge?



# Nits


The example in Figure 1/Section 4.2 uses the authority form of request,
unnecessarily. It is enough to include the path in the request line.


Sections 4.2, 4.3, and 4.5: check the list construction. If the list items are
sentences, those start with a capital letter.


In Section 4.3, grammar check: "replying with the following requirements" might
be more correctly "replying with a request that conforms to the following
requirements"


Section 10 uses ARP and CAM without expansion and misses NDP.


[1]
https://datatracker.ietf.org/doc/html/draft-rosenberg-internet-waist-hourglass-00 <https://datatracker.ietf.org/doc/html/draft-rosenberg-internet-waist-hourglass-00>
> https://datatracker.ietf.org/doc/html/draft-tschofenig-hourglass-00 <https://datatracker.ietf.org/doc/html/draft-tschofenig-hourglass-00> /
https://people.eecs.berkeley.edu/~alig/papers/http.pdf <https://people.eecs.berkeley.edu/~alig/papers/http.pdf>




--
Masque mailing list -- masque@ietf.org <mailto:masque@ietf.org>
To unsubscribe send an email to masque-leave@ietf.org <mailto:masque-leave@ietf.org>

Received on Monday, 26 May 2025 13:09:15 UTC