[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mech-v2-05pre


Before I dive into answering point by point your remarks, I am going
to summarize the point we've reached:

Positive:
- the major problem related to the source address has been resolved.
- editorial comments were I think, with one partial exception (Section 3.5. last paragraph), resolved.

This is very good, and encouraging progress!

Still to be resolved:
- Definition of configured tunnels in Terminology Section
- Some text delivering the right perception to the reader, that the
tunnel source address being configured is checked during the "tunnel
establishing phase", which is not the same with the "data exchange
phase" of the tunnel protocol, and is not the same with a CLI command acting on its own, with no coordination whatsoever with the protocol specifications.

So here it is:


Pekka Savola wrote:

On Mon, 23 Aug 2004, Alex Conta wrote:
[...]

Importantly, because the tunnel is a virtual point-to-point link, checking the correct tunnel entry point address, if it is being configured, is primarily a "protocol issue", so it belongs to the tunnel protocol engine, as opposed to the command used to configure the tunnel.

I disagree with this. This depends on what you define the 'protocol'. I define the protocol as a mechanism which runs between two IPv4
configured addresses: whether it has a chance of working or not
depends that the configuration information ("input function" if you
consider the protocol as a system) has been entered correctly.


1. You seem to view the encapsulation/decapsulation, which is the "data
exchange" part of the protocol, as the only part of the tunnel protocol.

So let me clarify:

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 specification states the requirements and the functioning for both. Some specifications are organized differently than others, some have distinct sections, some are split, some name one phase as an independent sub-protocol, but that ultimately is irrelevant.

The tunnel creation is the "establishing phase of the tunnel protocol",
which is part of the "protocol control phase". Removing a tunnel, which
is the "tear-down phase of the tunnel protocol" is also part of the
"protocol control phase". These are protocol phases even though there is
no message exchange.

So there are two phases of the tunnel protocol:
- "control/setup" (establishing, tear-down) and
- "data exchange" (encapsulation/decapsulation).

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

You probably think that it's protocol's job to deal with
misconfiguration, and a BUG of the protocol if it doesn't; my
assumption is that the protocol must work correctly with the correct
configuration, and nothing more is required.

2. Let me clarify: the protocol specifications is supposed to state the requirements for the setup/control and data exchange phase, for the protocol to function correctly. When any of the requirements of protocol setup/control are not met, we deal with a protocol misconfiguration problem.

The Tunnel Protocol setup - the tunnel configuration - regulated by the tunnel establishing phase specification, is implemented in most cases with some split between a CLI command - 'ifconfig' for instance, and the "protocol control" section of code in the tunneling module (tunneling driver, kernel, or whatever name may have). The former is invoked and passed parameters by the user/administrator, the latter is called, under soma form, for instance system function call, and passed some partially pre-processed, or fully processed parameters, by the former.

Again, the two components - 'ifconfig'(a) and 'tunnel establishing phase' code in the tunnel module (b) - act together in configuring tunneling, following the requirements and functioning set forward by the protocol control phase specification. Detecting any requirement of this phase that is not met, whether detected by (a), or by (b) is communicated to the user: directly by the former (a), or through the former(a) by the latter (b).

The data exchange phase of the protocol is implemented entirely in the tunnel module. The requirements for its correct functioning are dealt with the implementation of this phase, and appropriate error notifications are sent to the client, with ultimate target the user, or administrator.

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.

This is what I was suggesting you to try understand and address.

The correct analogy between this type of tunnel and a TCP, (or connected UDP) communication was made in some earlier messages, in that the "bind" function call implementation, called when "binding" a TCP, (or UDP) socket to an address, checks that the address belongs to the node.

That is IMHO a bad analogy as I pointed out. TCP and UDP are
user-level protocols, requested by applications which have no specific
rights or privileges.

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. The analogy is also valid in what concerns separation between control functions and data exchange functions of the protocol:

- the tunnel "establishing phase" corresponds to the establishing of the
TCP virtual circuit, or a connected UDP, as a protocol control function.

- the tunnel  "tear-down phase" corresponds to the closing of a TCP
virtual circuit, or a connected UDP as a protocol control function.

- the tunnel "data exchange phase", corresponds to the TCP, or UDP data
exchange phase.

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


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.

Protocols must not require being designed to work with incorrect input
from the administrators.


If I parse this correctly, this is a misunderstanding. I have not said
this.

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.


Remember, the protocol can be setup by using some commands (CLI), but it can be setup also by calling directly function calls or entry points in the "protocol setup code".

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.

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.

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.

The point is that, the configuring of the tunnel is split in
b. and c., and the functions performed by b. and c. are following the protocol setup functions set forward by the specifications. Assuming (b)'s functions 'bf', and (c)'s functions 'cf', and the functions required by the specifications 'sf', the following equation reflects a correct implementation:

bf + cf = sf      (eq)

The choices an implementer has are:

i. not to follow the specifications, in that case:

bf + cf < sf

or,
ii. how much of 'sf' to put in 'bf', or in 'cf'. In some implementations

bf > cf, in other bf < cf, in other bf = cf.

The correct implementation is always reflected by the equation (eq).

I hope this helps.
[...] 

Comment 1 (major)
-----------------
Page 4, Section 1.1, Configured Tunnels

        .... behaving as virtual point-to-point links
        between the IPv4 tunnel endpoint addresses.

Problem:

"virtual point-to-point links between ..addresses", introduces a new and faulty concept.

IETF, and other standards bodies are very clear on these concepts:

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

This is funny, it really is: I suggest this as good material for April
1st (Fool's day) RFC.

- nodes are attached to links through interfaces
- addresses are identifiers of interfaces on the link, and network.


As I said, IETF and other standards; please check IETF RFC 1812,
MIL-STD-188,  ATIS/ANSI Glossary, IETF RFC 2460, IETF RFC 2461, to
mention a few.

Suggestion:

replace "addresses", with "nodes", or
remove "addresses", and make "endpoint" plural, i.e. "endpoints".


No; the fundamental presumption of the current specification is to
provide a tunnel between configured *addresses*, not *nodes* (which
could have multiple addresses). As the new security checks etc. prevent the use of more than one address per node, we must spell out
the assumption that we want p2p between addresses not the more generic
p2p because it doesn't work.


Seriously now, as far as I can say, some liberties were taken here, and
quite a bit of bending to make things fit, not to say more...

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!

Even though they are abstract concepts, they have a direct correspondence to physical reality:
- nodes are systems; they are either clients of the network (hosts), or serving network infrastructure functions (routers, switches).
- a link interconnects nodes (systems)
- a network is several links, a data communication infrastructure (cable or wire) interconnecting multiple nodes,

Ultimately, I have not seen much discussion about this, since I started following this list, I know I voiced my non-enthusiasm in the context of this tunneling specification, but I have not followed
closely this WG before... Can you point to some WG discussion on this
topic?, some WG consensus? some standards defining such ptop links?...


Comment 2
----------
Page 8, Section 3., last paragraph, and all other occurances

..... protocol-41, or protocol 41...

Problem: language

Suggestion:
replace "protocol-41", or "protocol 41" with
"IPv6 in IPv4 tunneling protocol"
This doesn't seem a good approach, because protocol 41 is very specific. There could be other v6-in-v4 tunneling protocols which might not use protocol 41. It's better IMHO to use protocol-41 which is short and accurate (as far as it can be accurate).

It is common practice in good specifications - take IPv6, or IPv6 ND.
I would use the official name under which protocol 41 is assigned.
There can't be confusion there...

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.


Comment 4
----------
Page 15, Section 3.5, last paragraph

... tunnel peer has configured...

also penultimate sentence of paragraph

Problem:language; the "tunnel peer" is the object of configuration and not the agent performing the configuration.

Suggestion:

replace "has" with "was".

sentence is still awkward, and unclear. Replacing text was suggested with earlier message.


I can't parse the sentence if I change "has" to "was" so I guess you're reading it differently than I am.

Would it be clearer to just remove the text about tunnel peer (because
it's now stated just before section 3.1) and change to singular for
clarity, like:

When encapsulating the packets, the node must ensure that it will
use the correct source address so that the packets are acceptable to the decapsulator as described in Section 3.6. [...]


This is much better. It is clearer, and does the job for me.

Comment 5
----------
Page 21, Section 5.

    -   IPv4 source address of the packet MUST be the same as configured
        for the tunnel end-point,

problem: ambiguity in text; as it is a bi-directional tunnel, the tunnel end-point is configured with a reverse path tunnel, i.e. a source address, which is one of the decapsulator's addresses. Without qualifiers, "configured" can be understood as applying to several things, in which "source address" is different.

Suggestion:
replace with:
"IPv4 source address of the packet MUST be the same as the tunnel entrypoint address configured for filtering purpose in the tunnel exitpoint (decapsulator)


I've wanted to avoid introducing the entry/exit point terminology, and I don't want to say that the entrypoint is just configured for filtering purpose; it's dually configured for the purposes of sending packets to that address, so I don't think it needs to be said here.


In the problem description above, I pointed out exactly to this type of
confusion, which you mentioned here.

Try to put yourself in the shoes of a first time reader. The
interpretation should not be ambiguous, and not different from that of
the familiar reader of the spec.

Further, these bullets are just referring & summarizing the checks
earlier in the draft, so I don't want expand it a lot here, rather
just include a referring pointer if really necessary.

Would adding a referral to section 3.6 help, like replace:

   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.

In the same time, there is the suggestion or reminder that Security
sections are almost independent sections, with a life of their own, so
repeating some stuff may not hurt.

Thanks!

My pleasure, I hope it helps. We move forward and that is very positive.
I appreciate that.

Regards,
Alex

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature