[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Pekka Savola wrote:

[..] However, we've concluded that configuring the tunnel
source address does provide utility.


It seems as forgotten, or ignored that the utility of configuring the address is bound to the space of the node's addresses.

As a reminder, *its utility* was spelled out in Section 3.5 (it is true rather awkwardly) as to avoid possible oscillation of the source address as consequence of selecting repetitively alternate outgoing interfaces during routing system instability.

Outside those boundaries there is no utility, or at least none was
spelled out in the spec.

[...]It would force the implementors to add such checks. 

The check falls nicely into place with the selection
of the route and outgoing interface.

That might be
unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4
addresses. 

If a router has that many addresses, rest assured it has also the
appropriate mechanism to match quickly anyone of them.

It would add an additional requirement to the spec 

A general requirement for any RFC is to have NO protocol BUGS.
As a DRAFT standard, that becomes A MAJOR requirement.
Additionally, it MUST NOT introduce bugs that didn't exist
in the previous incarnation of the document.

(i.e., make the spec more complex).

The change would fix a BUG in the spec. Of course sometimes correct specifications require more text than the buggy ones.

If the above complexity statement is to say that the complexity in this case is beyond the current editor's abilities, we should keep in mind that Erik volunteered to make the appropriate change.

It would require re-spinning the
document and putting it through IESG evaluation again. 


Don't you think the IESG would like to do a reevaluation anyway?

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


Indeed, configuring the tunnel source address versus using the address of an outgoing interface address, is like *binding* the TCP socket, versus using a *non-bound* socket.

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


Unfortunately, without the correction in this spec, the administrator would have to read a lot more than this specification, for the tunnel to be always configured correctly. This specification, as it is, would not help anyways...

But the specification is not only for the administrator.

The check for a configured "source address" must be implemented, and it is analog to the address check performed by a TCP socket "bind" call.

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.


If the spec were correct, this guidance would follow the spec, and say that the source address must be one of the node's addresses.

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,

That is not obvious at all, unless the administrator is intimately familiar with tunneling requirements.

or just leave it empty -- and then it's automatically determined.

This is just routing 101:

Oh... so now the requirement for the users of this tunneling, for instance the laptop or PC owner/user to have taken IP 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.


...which of course requires the laptop or PC user to have taken also ICMP 101....

This is not acceptable...

[...] 

Regards,
Alex

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature