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

On Mon, May 26, 2025, at 23:09, Mirja Kuehlewind wrote:
> 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?


This part was really just setup for the next paragraph.  The advice you have about VLANs is entirely appropriate.  It's fine if there is some out-of-band mechanism to communicate what VLANs mean and how to arrange them, but it is the presumption that this be part of the protocol that is where the problem comes in.

> 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?

I would not have raised an issue if I didn't think it was a problem.  Mimickry is not a great basis for engineering.

I also tend to think that the use of these in connect-ip and connect-udp are unnecessary, as opposed to using a URI template.  Here, the problem is far more acute.  At least with connect-{ip,udp} there is a chance that the parameters make sense without some special back channel.

> 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?

It seems like there should be an established understanding of what side of the bridge has things like gateways and so forth.  Otherwise, this won't interoperate very well.

Another thing to perhaps consider is whether the proxy could do MAC rewriting.  I don't think you should mandate something like that, but it's an option.  You definitely should default to a mode where clients are only able to join just a single MAC to the network.

I know that's more stuff to write down and that there will always be cases where people want to violate that, but setting down expectations for something like this is far more likely to lead to something that is useful than relying on deployments to get all the details right.  If you say nothing, you force every client to negotiate everything prior to even sending the CONNECT request.

If nothing else, these are serious operational issues that a proxy needs to contend with.  If you expect this to be deployed, then maybe those who know this inside out will get that right, but it's anyone's guess what comes after that.

Received on Monday, 26 May 2025 23:08:06 UTC