Re: mech-v2-05pre

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 24 Aug 2004, Alex Conta wrote:
> The tunnel protocol, like any other similar protocol, has two phases: a
> protocol setup phase (a), which can also be called protocol control, and 
> a protocol data change phase (b).

The protocol setup phase in this protocol is "administrative 
configuration".

> This is quite similar to other protocols that create links, or virtual
> links: PPTP, L2TP, PPP, ATM VC, FR VC, etc...

All of these also include a lot of other negotiation.  Configured 
tunneling has no negotiation, and that's on purpose.

> It seems that your interpretation, passed to the text of the 
> specification, and consequently perceived by the reader, that there is a 
> complete disconnect between the protocol and its configuration, and that
> configuration is somewhat performed and successful by chance, and not by 
> following some clear specifications.

Yes, there is a disconnect between the data exchange and configuration 
in a sense.. that's because the data exchange should not need to care 
whether the configuration has been correctly entered or not.

Remember, the "setup phase" of the protocol does not even provide
positive acknowledgements when a tunnel has been set (on purpose!), so
you'd have to rely on negative acknowledgements.  But as that hasn't
been widely implemented, and will not be such, you cannot rely on
negative acks either.  So you'd end up in a situation that sometimes
you might get a negative ack ("the other end has not configured a
tunnel, this won't work"), but as you can't rely on getting those,
you'll have to do some other testing of the tunnel (e.g., by pinging
in any case).

The more complex protocols you list include an explicit negotiation
phase, so this is not an issue, but here the goal was to produce a
simple tunneling specification which relies on *manual*, correct 
configuration.
 
> > Setting up tunnels *always* (AFAICS) requires special "administrative"  
> > privileges.  It's not meant to be used by regular users and apps in
> > any way they feel fit.  Sure, if they're given sufficient permissions,
> > they could set up tunnels, but it comes with the caveat that they must
> > know what they're doing.
> 
> 3. This is not really relevant for the essential point of this message,
> nevertheless some clarification is in order:
> 
> For what is worth, I know you pointed out, but it was pointed back to
> you, why the analogy is valid. The analogy is valid, in terms of source
> address check by TCP socket "bind" (connection setup), similar to tunnel
> establishing phase source address check. [...]
> 
> You are right that privileges are required. But they may have just
> been misleading, since they are not relevant, even if at a closer, we
> realize that there is no difference: a tunnel interface creation 
> (ifconfig) is a command requiring user privileges, but so are using 
> certain TCP and UDP ports that require user privileges

Again, TCP "bind" is not IMHO a valid analogy.  Users can create such 
sockets and you have to do more scrutinous checks on the input.  While 
the users can run ifconfig, they have no privileges to actually create 
the tunnels.  So this is different.

A closer comparison (though not 100% accurate) IMHO is whether a host
must prevent the node from sending out packets with wrong source
addresses w/ raw sockets.  The permissions required for this and
configuring the tunnel are the same.

> >>Currently, the specification seem to suggest that the checking is a 
> >>"configuration command issue", and that is false: it is a "protocol 
> >>setup issue", with appropriate place to address in the protocol setup 
> >>mechanism.
> > 
> > As stated above, I disagree with this interpretation of the protocol.  
> 
> If you disagree, it means you're assuming that the CLI command is
> performing entirely the tunnel establishing phase, and that the
> establishing phase is not part of the protocol. These assumptions
> are both incorrect. Ifconfig, and BSD IPv6 in IPv4 tunneling are a
> good example.

I didn't think ifconfig was a good example of "tunnel establishment
phase".  If you configure the tunnel with an ifconfig command (for
example), then it has already been established as soon as you'll
receive no error code from the command.

> But I am saying that a correct protocol specification will require that
> incorrect input from the administrator does not pass undetected the
> control functions phase of the protocol.

But that's still saying that the implementations will have to 
sanity-check the input given by the administrators.  Some 
implementations may want to do that, but as I showed, all of those I 
personally looked at didn't bother to do so.

The principle is that the admin can shoot itself in the foot, and if 
the tunnel doesn't work, he can only blame himself for 
misconfiguration.

> > I fail to see the analogy.  If you don't use CLI (which is implicitly 
> > assumed), it's an implementation issue to deal with the consequences, 
> > i.e., appropriately define the checks to the function calls to make 
> > the protocol work better even with wrong input.
> 
> Let's clarify the steps:
> 
> a. The administrators enters a CLI command to configure the tunnel. The
> tunnel source address parameter entered with the CLI command is verified
> by the administrator, who also must be privileged to invoke the command.

Yes.
 
> b. The CLI command does some pre-processing and validates that the 
> tunnel source address is a valid IPv4 address. For instance returns an 
> error if the source address specified is 01::0d:05:e0:f5.

The implementation probably does a syntactic check yes, but that's an 
implementation decision.
 
> c. The "tunnel establishing phase", part of the tunnel protocol control
> function, which is invoked through a system function call, plugged into 
> the tunnel module, validates further the pre-processed parameter, for 
> instance that the IPv4 address is one of the node's addresses. For 
> instance returns an error if address 1.2.3.4, which passed (b), is not 
> 2.3.4.5, and 3.4.5.6 the two ipv4 addresses of the node.

No, the tunnel establishment phase doesn't need to verify this (even
though it can if it wants).  I gave you 4 implementation examples
where they DON'T check this, and IMHO it's a good thing (because I
have a firm belief that we must not mandate the implementations to
"babysit" the operators, but I acknowledge that some implementations'
user base may be such that they require serious babysitting).
 
The current text in 05pre just clarifies that if the address isn't 
configured on the node, it's probably a misconfiguration -- but it 
doesn't mandate checking the address.

> >>- Point-to-point links are between two nodes
> > 
> > Please provide a pointer to such concept because I haven't heard of
> > such consensus.  Point-to-point can be whatever we define it to be as
> > long as the definition of "point" is clear, which is exactly what I
> > was doing :-).
> 
> So, you define a v-link between *addresses*, then you would define
> interfaces, which are the attachment points of the *addresses* to the
> v-link, and than you would define the addresses of these interfaces,
> that identify these interfaces. So you would end up with addresses of
> attachment points of *addresses* to the v-link...(-:

There is no reason AFAICS why you need to be concerned what are the
attachment points of the addresses.
 
> This is funny, it really is: I suggest this as good material for April
> 1st (Fool's day) RFC.

I really hope it doesn't get that long for the RFC editor to produce 
this RFC, but April 1st is otherwise as good as any to me :-).
 
> The concepts of network, links, interfaces, addresses, are part of the 
> Internet Architecture, they are strongly inter-connected,  and 
> inter-dependent, and you cannot simply change the definition, or the use 
> of one the concepts, without defining a new architecture: Good luck if 
> that's what you intend!

I think you're concerned about this from the pedantical perspective.

If we wanted to be 100% accurate, I guess one could reword:

All tunnels are assumed to be bidirectional, behaving as
virtual point-to-point links between the IPv4 tunnel endpoint
addresses.

to something like:

All tunnels are assumed to be bidirectional, behaving as virtual
point-to-point links between nodes, using the specified IPv4 
addresses as tunnel endpoints.

.. because the p2p links are between the nodes, the text above just 
makes it clear that the tunnels are tied to a particular address of a 
node, and they cannot be used except with that single address of the 
node.  So I'm don't think it's worth changing the above because
it doesn't increase clarity of the definition, just decreases it.

> >>Comment 3
> >>----------
> >>Page 15, Section 3.5
> >>
> >>                 An IPv4 address of the encapsulator: either manually
> >>                 configured or an address of the outgoing interface
> >>
> >>problem: language
> >>
> >>Suggestion:
> >>replace with:
> >>	
> >>                 An IPv4 address of the encapsulator: manually
> >>                 configured or automatically selected from the addresses
> >>                 of the outgoing interface
> > 
> > 
> > Could your suggestion be interpreted that the manually configured
> > address must be an address of the outgoing interface?  That would be
> > wrong, because it can be e.g., the loopback address.  I don't see how
> > your suggestion clarifies.
> 
> I see your point, you are right. Switching places would do it:
> 
>          An IPv4 address of the encapsulator: automatically
>          selected from the addresses of the outgoing interface
>          or manually configured.

Compared to the current text, this has switched the order, removed
"either" (which seems like a no-op), and included "automatically
selected from the [addresses]", which is IMHO worse.  That's because
automatic selection should really not be used when there are multiple
addresses (because the results will likely not be deterministic, and
the decapsulator must have the correct configuration) -- you cannot
rely on automatic configuration getting it right!  So, I'd like to
avoid giving the expectation that automatic selection would work w/
multiple addresses.., hence I'd prefer to leave it as-is.

> >    Therefore, this memo specifies that the decapsulators make these
> >    steps to mitigate this threat:
> > 
> > with:
> > 
> >    Therefore, this memo specifies that the decapsulators make these
> >    steps (described in Section 3.6) to mitigate this threat:
> > 
> > .. or some other smaller change?
> 
> Probably yes.

I've only done that, in order to keep the changes at the minimum and 
to not repeat the whole checks in Security Considerations; it's only 
meant to be a summary of them in any case.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings