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

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

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

And if the editor if the document is unwilling to add one sentence I hereby
volunteer to add it to the draft.

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

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

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

Existing protocol specifications leave it open to what happens with existing
communication, such as existing TCP connections, when the IPv4 address of
the node is changed.
For that reason I don't think we need to say anything but a "MUST" (or
"SHOULD") be an IPv4 address assigned to the encapsulating node, and leave
the dynamic aspects unspecified. 

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.

   Erik