Re: mech-v2-05pre

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 23 Aug 2004, Alex Conta wrote:
> > It appears that there is at least some form of support of clarifying
> > the text to more clearly state that the tunnel entrypoint should be an
> > IPv4 address of the encapsulator. However, there are reasons (e.g., as
> > Stephen mentioned) why checking this at configuration time might not
> > be beneficial, and others also think this is an implementation detail.  
> 
> Perhaps you have not read the last message Stephen sent on the 
> discussion thread; as it turns out, the implementation Stephen mentioned 
> does perform an address check, on the completion of the interface 
> configuration operation.

Yes, I did read it.  But because the check is made later in the
process, after already configuring the tunnel (but rather when
deciding whether it's feasible to being operationally enabled or not),
it's entirely different issue -- which cannot be tackled without going
in depth to the operational status issue which is IMHO something we
should not do.  The point which was made that configuration-time
checking has drawbacks, and that's one reason we don't want to
recommend it, but leave it entirely up to the implementors.
 
> 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.

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

> 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.  
Protocols must not require being designed to work with incorrect input
from the administrators.

> 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.
 
> However, I am going to point out once more, that configuring a 
> bi-directional IPv6inIPv4 tunnel, should align with configuring other 
> bi-directional tunnels (PPTP, L2TP, MPLS etc...), and other links, or 
> virtual links(PPP, ATM VC's, FR VC's,...) where the configuring provides
> an error notification mechanism in case misconfiguration prevents a 
> correct establishing of the tunnel, or link.
> 
> This alignment is necessary not for appearance reasons, but for sound 
> design and operational reasons, which pointed the above mentioned 
> protocols to implement such error notifications.

As noted offlist, these examples are not close to what this spec is 
aiming to do.  This is intended for a very simple mechanism, requiring 
*manual* configuration.
 
> Another comment, which I consider important:
> 
> Orthogonal to the error notification, the introduction of 
> bi-directionality without support of passing/negotiating configuration 
> information automatically between the two end nodes of the tunnel, 
> similar to other bi-directional tunnels, links, or virtual links 
> (mentioned in previous paragraph) leaves the protocol look as incomplete 
> ('half baked').

Again, such protocols can be specified and used in conjuction with
this spec, to help set up the tunnels.  See for example TSP.  Or you
could just use L2TP instead, that provides v6 support out of the box.

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

> - nodes are attached to links through interfaces
> - addresses are identifiers of interfaces on the link, and network.
> 
> 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.

> 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).
 
> 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.
 
> 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. [...]
 
> 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.

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?

Thanks!

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