Re: misconfiguring the tunnel source address [mech-v2-04]

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 20 Aug 2004, Erik Nordmark wrote:
> My concern is that there is nothing in the document which says it would
> be a misconfiguration. The document is utterly silent on which addresses
> can and can not be configured as the source address of a tunnel.
> Thus even though we all know that it must be an address configured on the node
> an implementor can not read that in the specification.
> That is the thing that needs to be clarified.

But the point is, why exactly should the implementor need to care at
all?  The administrators can *always* break any protocol they want by
misconfiguring it.  Why is this special?

My assumption as the operator of the networks, hosts, and servers is
that *I* know what I want to configure.  That's what "root" access is
for ;-).

To the administrator, it should be obvious that it needs to configure
a source address that is on the node if it expects the tunnel to work.
If the tunnel doesn't work, the administrator goes back and checks the
settings, runs some tcpdump or whatever, and figures out (s)he
misconfigured the address, and fixes the problem.

I think you have the assumption that the implementors must verify that
the users don't enter invalid configuration, configuration which
should not work.  As I noted, currently the implementations don't seem
to have that assumption, because they haven't implemented such checks
-- they just want to keep the protocol simple, and give the control
(and responsibility) to the user. (Remember, not every user even needs
to configure the source address.)  If the implementors' target
audience are administrators who are believed to misconfigure the
source address settings, then it might be worth the added 50 lines of
code, testing, etc. that would ensue (remember, there may be scaling
issues with 100's or 1000's of addresses).  Or it might not be.

That said, I don't strongly object to briefly mentioning something
that source address is expected to be an address configured on the
node, but I fail to understand the urgency of this, and why this is
such a big issue.

> > Some implementations will want to check that, no matter whether it
> > reads in the spec or not; some others might not want to bother, rather
> 
> The way the document is currently written I could argue that an implementation
> which decides to check does not conform with the specification.

That would be reading the spec by the letter, and not by the spirit, 
and even then it would probably be a close call.

> > If I read correctly what you refer to with "minor clarification", I
> > think you would be satisfied with just a hint to the implementors that
> > they might want to check that the source addresses belong to the node,
> > but add no MAY/SHOULD/MUST terminology.  Correct?
> 
> Incorrect.
> For the protocol to work the source address of the tunnel must be an IPv4
> address assigned to the node. So this sure sounds like a MUST as far as I can
> tell.

What would be the goal of checking for source address at tunnel set-up
time?  The v4 address of the node could change from underneath the
tunnel, and then the ICMP errors would get lost in any case and the
tunnel would cease to work.  In other words, the user could just
change the v4 address to A, set up the tunnel from A->B, then change
the address to X (these require the same amount of privileges!).  Do
you think that also would need to be protected against (IMHO, totally
unfeasible), or is just one-time user configuration check sufficient?

> I think we should ask ourselves what behavior would such a MUST exclude that
> we should not exclude because it has some non-zero value for the user.

It would force the implementors to add such checks.  That might be
unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4
addresses.  It would add an additional requirement to the spec (i.e.,
make the spec more complex).  It would require re-spinning the
document and putting it through IESG evaluation again.

I'm not sure if I can think of concrete deployments where you would
actually want to configure a different source address.  Maybe related
to IPv4 renumbering, but even that's a bit of a stretch.

I.e., my main concern is that this doesn't look like a protocol issue
but rather user interface/configuration issue which is
implementation-dependent.

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