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

Hi Martin,

Thanks for the review.  Apologies for the delays on my part, I've been
on vacation and am just getting back to this now.  I think Mirja covered
most of what I was going to say already; my own replies are inline.

"Martin Thomson" <mt@lowentropy.net> writes:
> 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'm inclined to split the vlan-identifier text and examples into a
separate paragraph with a bit more focus on the "implementations MAY"
aspect of it.  I do not want to go into details of how a vlan-identifier
parameter might be encoded since that should involve some out-of-band
communication.

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

Here, as Mirja said, I'm going for consistency with the rest of the
MASQUE suite.  Would it be more palatable if the /.well-known/ example
was only for the non-parameterized case and not the hypothetical and
underspecified vlan-identifier case?  Adding the "ethernet" entry to the
"masque" table in the .well-known registry is cheap, and registering it
now means it's available for future extension work.

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

Would arbitrary work better than falsified here?

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

I disagree.  There are use cases I can imagine (though perhaps slightly
contrived) where an isolated Ethernet segment gets bridged to a client
providing a gateway for the duration of the session.  There are also
cases where there may not be any gateways, and all communication is only
between nodes on the segment.

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

MAC rewriting sounds a little too much like NAT for my taste.  We could
add a suggestion to limit clients to a single source MAC address by
default in the Security Considerations, not as part of the protocol, but
as something implementations may choose to do.  I wonder what fraction
of the use cases will be point-to-site vs site-to-site.

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

I expect connect-ethernet deployments to be very particular and often
used between endpoints controlled by the same party.  Maybe that is due
to a lack of imagination on my part.  For most use cases—not all or I
wouldn't be writing this draft—I would expect that using higher-level
mechanisms such as connect-ip or connect[-udp] would be superior.
Perhaps the draft should make that more explicit and encourage readers
to consider using higher-level options first.

Received on Thursday, 29 May 2025 15:09:07 UTC