draft-ietf-masque-connect-ethernet-06 early Httpdir review

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.

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.

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.

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.

# 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-tschofenig-hourglass-00 /
https://people.eecs.berkeley.edu/~alig/papers/http.pdf

Received on Wednesday, 14 May 2025 05:31:27 UTC