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

[Radhakrishnan Suryanarayanan <rkrishnan.s@samsung.com>]

As an implementator even though we have made sure that such
misconfigurations do not bring up the tunnel interface, I dont think there
is any harm in adding a sentence which conveys that such misconfigurations
doesnt guarantee proper working of the tunnel.

----- Original Message ----- 
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Erik Nordmark" <Erik.Nordmark@sun.com>
Cc: "Alex Conta" <aconta@txc.com>; <v6ops@ops.ietf.org>
Sent: Friday, August 20, 2004 4:42 PM
Subject: Re: misconfiguring the tunnel source address [mech-v2-04]


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