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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 20 Aug 2004, Erik Nordmark wrote:
> > 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?
> 
> So you are saying e.g. the TCP checksum algorithm should be configurable so
> that administrators can make TCP not interoperate by chosing a different
> checksum algorith? 
> That wouldn't provide any utility.
> So what utility do you see in extending the configured tunneling
> to allow any IPv4 source address?

No, I'm not saying that and I think you know it :).  There is no
utility in the TCP specification for the user to manually configure
the checksum.  However, we've concluded that configuring the tunnel
source address does provide utility.

On the other hand, for those who want to manually configure the TCP 
checksums, there are raw sockets.  So, I think a closer analogy would 
be, should a node restrict the applications using raw sockets from 
sending out packets with wrong source addresses?

I think you agree that this should not be required.

> [Out of order]
> > > 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.
> 
> These are not benefits to the user. They benefits you claim are for
> the implementer and the editor of the document.
>
> The implementer's issue isn't any different than establishing a TCP connection,
> where a source address assigned to the node needs to be selected. So I think
> that is a red herring.

Tell me of an implementation where a regular user or regular
application would be allowed to set up a tunnel, and even more than
that, specify the source address even if the tunnel is set up?  No--
this is different, because it is manually configured by the
*administrator*.

However, TCP does provide this "basic" functionality to the 
applications and regular users.  Configuring v6-in-v4 tunnels doesn't 
appear to do that.

Also remember that the users of a protocol specification are mainly
the implementors.  For operational documents, the target audience is
closer to the (knowledgeable) users.
 
> > 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.
> 
> If there is an issue with IPv4 renumbering, wouldn't that also imply that
> one must be able to create TCP connections with an IPv4 source address
> which is not assigned to the machine?
>
> I think renumbering issues place constraints on the ordering of actions,
> and the tunnels isn't qualitatively any different than other ordering 
> constraints.

As said, TCP provides a different kind of services to different users 
and applications, so this is different.  But this isn't worth the 
argument as it's just a vague possibility.

> > 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.
> 
> Assuming the administrator reads the protocol specification, can you please
> quote the part which will make it obvious? I sure haven't found any such
> text which is why I'm quite concerned.

Why do you assume that the administrator *needs* to read the 
specification?

The administrator learns that he can set up IPv6-in-IPv4 tunnel using 
command X (and it's suboptions), from the vendors documentation, man 
pages, or whatever.

There he sees guidance that he can provide the source and destination 
address of the tunnel.

Without any description, it is obvious that the administrator who 
wishes to set up a tunnel from node A must configure the source 
address from node A as a source address, or just leave it empty -- and 
then it's automatically determined.

This is just routing 101: if you don't put in a right source address, 
the return packets don't get to you and it won't work.

> > 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
>
> To repeat, my concern is that the document in its current state
> reads as if any IPv4 address can be used as the source address of a
> configured tunnel, which we all know isn't the case. But one can't
> read that from the document. If I'm mistaken, please quote the text
> in the document which says otherwise.

I don't argue that -- I just point out that if the administrator
explicitly configures a wrong address, it's sufficiently obvious that
the tunnel won't work.

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