Subject: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt"

From: Alex Conta <[email-masked]>
Date: Fri, 13 Aug 2004 12:58:00 -0400

All,

Apologies for not bringing this up earlier on the WG list. The reason is 
that I noticed  this (see bellow) incidentally: it was not part of 
activity in the WG or IESG.

So I spoke about it with Erik N. and Pekka S. informally in San Diego. 
The message bellow was a reminder of the conversation.

What seemed to me to be a minor editorial correction solving a much 
bigger potential technical problem, has evolved in a debate, and both 
Pekka, and Erik asked me to bring this to the list, for both technical 
and procedural reasons. So please see bellow my original message.

Regards,
Alex

Alex Conta wrote:

> Hi Pekka,
> 
> This is a reminder of the usefulness of a clarification in 
> "draft-ietf-v6ops-mech-v2-04.txt" in respect to the tunnel entry-point 
> address being one of the encapsulator node's addresses.
> 
> Currently there seem to be an ambiguity regarding the IPv4 address of 
> the tunnel entry-node in "draft-ietf-v6ops-v2-04.txt".
> 
> A clarification would be useful, stating that the tunnel entry-point 
> address of an IPv6 in IPv4 tunnel must be an address that belongs to the 
> encapsulator node.
> 
> Note that one of the consequences of configuring a tunnel with a tunnel 
> entry point address which does not belong to the encapsulator is that 
> ICMP messages referring to encapsulation errors, and thus destined to 
> the encapsulator, may not reach the cause of the error, which is the 
> encapsulator.
> 
> Regards,
> Alex Conta

---

From: Pekka Savola <[email-masked]>
Date: Fri, 13 Aug 2004 21:40:02 +0300 (EEST)

> > the encapsulator, may not reach the cause of the error, which is the 

The proposition was to add language something like "the implementation
MUST verify that a manually the source address, if manually
configured, is an address of the node" to section 3.5.

With the editor and co-chair hats on, I have argued against this
because:

 1. the document is already past the IESG evaluation, with just one 
    discuss item to be cleared, and likely won't even need to be 
    revised.  We should not change it unless there are 
    significant problems.

 2. this is (IMHO) a user-interface issue, does not affect protocol 
    interoperability, and does not belong in the specification 
    (especially not in the uppercase, or mandated).

    That is, such a check could be used to mainly prevent the user
    from misconfiguring the source address ("shooting himself in
    the  foot").  Some implementations may want 
    to do that, some other might not: after all, it's the 
    administrator who's doing the configuration.  (I don't think the 
    IETF protocols typically provide mandatory provisions to prevent 
    misconfiguration by network operators/administrators.)

    On the other hand, I wouldn't see a big problem in adding a small 
    warning about this, as a reminder that the implementation may want 
    to consider this except I think it would be redundant information
    -- if it wasn't for the fact that the document is already
    basically out of the hands of this WG.

So, in summary, I think this is an implementation issue which doesn't
need to go to the spec, and because we're already pretty far in the
process, I'm arguing against it.

But I'm interested in hearing what the WG thinks about this.

Especially input from implementors would be appreciated (i.e., whether
you think adding that kind of specification would be useful or not).

(hats off)

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

---

From: Alex Conta <[email-masked]>
Date: Fri, 13 Aug 2004 16:00:16 -0400

Pekka,

Pekka Savola wrote:

> [...] 
> [...]

I am surprised to see here an interpretation of what I suggested (and 
Erik N. supported), which is not accurate, or correct. Originally, and 
as a primary importance, I (and Erik N.) referred to the following text 
in Section 3.5:

               Source Address:

                 IPv4 address of outgoing interface of the encapsulator
                 or an administratively specified address as described
                 below.

and suggested replacing it with the following text:

               Source Address:

                   IPv4 address of the tunnel entrypoint (encapsulator).

to which in your message of 8/12/04 6:12pm, you replied to me, with CC 
to Erik N., Bob G., and David K., that it it would be OK (see excerpt 
from your reply)

--- beginning of excerpt
 >Suggested text:
 >>
 >>        Source Address:
 >>
 >>              IPv4 address of the tunnel entrypoint (encapsulator).
 >> 		
 >>

Would be OK, I guess.

-----end of excerpt

This is confusing. You seem to have changed your mind. Do you agree or 
not to this change?

This suggested text above is fixing a fundamental protocol problem, that 
I and Erik N. pointed you to, which makes no sense wasting time arguing 
if you maintain your position to agree to the change.

The secondary importance text at the end of Section 3.5, that need 
changing, and to which I made suggestions, as well as some text in 
Section 3.6, which turns out at a careful reading to be confusing, can 
be discussed separately.

Regards,
Alex

---

From: Pekka Savola <[email-masked]>
Date: Fri, 13 Aug 2004 23:19:42 +0300 (EEST)

On Fri, 13 Aug 2004, Alex Conta wrote:
> Erik N. supported), which is not accurate, or correct. 

You didn't provide your explicit suggestion so I had to try to
summarize the best I could the point which seemed to be the root cause
for our debate :).

> Originally, and 
[Pekka:]
> This is confusing. You seem to have changed your mind. Do you agree or 

I see no major fundamental objection to just making that particular
change (except I'd rather avoid it due to being late in the process).  
Why I wrote it as above was that while I saw no fundamental problem
with that particular change, its usefulness seemed to depend on other
changes which I was having bigger objections towards.  That is, it
didn't seem that this particular change alone would have satisfied all
of us, and that was the reason for my wariness.

> Section 3.6, which turns out at a careful reading to be confusing, can 

If there is no need to make other than minor editorial changes in 
section 3.5/3.6 apart from the quote above, I wouldn't have major 
objections, but I'd still like to get input from the WG.

I just think it's more confusing if it's changed as you propose, if we
assume that the point of the protocol specification is not prevent
misconfiguration (but the implementations could, if they wish).  I
think this is the main point we need to get a feeling about first.

---

From: Alex Conta <[email-masked]>
Date: Mon, 16 Aug 2004 21:14:19 -0400

Pekka,

I am finally convinced: it is not easy to fix the document!

Sorry, IMHO the document is not ready for being published!

Unfortunately, the more you argued against the suggested change, which 
seemed very obvious and very easy, the more you made me go deeper into 
the document, and find one after another all sorts of smaller or bigger 
problems with the text, the protocol, or security of the protocol.

In conclusion, the document is not in a good shape, and I am sorry to
say it, but it is not ready to be published as an RFC, and even less as
a Draft Standard RFC. This document is not ready to replace RFC 2893.

Here are the problems and suggested text additions/modifications, which 
I hope will help.

Note: the original problem I contacted you about is included.

Problem 1
Section 1.1 Terminology

Insufficient text in definition.

Configured tunneling

                 IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
                 address is determined by configuration information on
                 the encapsulator.  All tunnels are assumed to be
                 bidirectional, behaving as virtual point-to-point links.

Suggestion:
change the definition of configured tunneling to:

---
Configured tunneling:

                  IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
                  address is determined by configuration information on
                  the encapsulator, and the tunnel entrypoint address is
                  one of the encapsulator addresses. All tunnels are
                  assumed to be bidirectional, behaving as virtual
                  point-to-point links.
---

Problem 2
Section 3. Configured Tunneling Mechanisms

Insufficient text in definition of mechanisms that need configuration

Suggestion:
Insert before the last paragraph (paragraph before the start of Section 
3.1) the following text:

---
     The tunnel entrypoint address is one of the encapsulator addresses.
     This address MAY be administratively configured, by manually
     selecting one of the encapsulator's addresses. The tunnel entrypoint
     address is used as the source address of the encapsulating
     header.

     The tunnel entrypoint address is also configured on the
     decapsulator,
     where it is used as a filter key to ensure that all packets
     received on the tunnel were sent from the tunnel entrypoint.

     The tunnel entrypoint address used by the encapsulator as source
     address of the tunnel packets and the tunnel entrypoint address used
     as a filter by the decapsulator MUST be identical.
---

Problem 3
Section 3.5 IPv4 Header Construction

  Following Text introduces protocol and security problem.
------
            Source Address:

------

Protocol problem:

- Potentially brakes virtual point-to-point link appearance of tunnel.
- Potential to defeat ICMP functioning in tunnel.
- Potential to defeat dynamic MTU, which is specific tunneling mechanism
- Potential to defeat IP fragmentation in tunnel.

Security problem:

- Makes very easy accidental or intentional defeat of tunnel packet 
filtering configured in decapsulator, documented in Section 4.

Suggestion:
Change Source Address text to the following text:

          Source Address:

                  IPv4 address of outgoing interface of the encapsulator
                  or an administratively configured address of one of the
                  encapsulator's node addresses.

Problem 4
Section 3.5 IPv4 Header Construction

Text of last paragraph is not sufficiently clear, language is confusing.

Suggestion:
Replace last paragraph with:

     The source address of the tunnel packets set by the encapsulator in
     the tunnel header MUST match the tunnel entrypoint address
     configured in the decapsulator.

     As the selection of the outgoing interface depends on the best route
     to the tunnel exitpoint, when an encapsulator has multiple
     interfaces
     and it is known to be operating in a non-stable routing environment,
     the selection of the source address as the address of the outgoing
     interface may oscillate among the addresses of the node. To prevent
     this oscillation, it may be desirable to administratively configure
     the tunnel entrypoint on the encapsulator, by selecting one of its
     addresses, and thus pin a certain address
     as the tunnel entrypoint. This would provide a stable source address
     in the tunnel
     packets that matches the tunnel entrypoint address configured in the
     decapsulator. Obviously, this requires that the administrative
     configuring of the tunnel entrypoint address on the encapsulator
     SHOULD be possible.

Problem 5
Section 3.6 Decapsulation

Language.

Suggestion:
In first Paragraph change "the packet is potentially part of a tunnel"
to "the packet is potentially a tunnel packet"

Problem 6:

Language

Suggestion:
Section 3.6 Decapsulation
In Second Paragraph, last sentence change "IPv4 address of the other end
of a tunnel configured on the node" to "IPv4 address of the tunnel
entrypoint. The tunnel entrypoint address is information configured on
the decapsulator."

Problem 7:
Section 3.6 Decapsulation

Black hole effect, in case one misconfigures the tunnel entrypoint, the 
tunnel exitpoint, or routing system instability causes source address 
oscillation.

Node which was misconfigured has no way of finding out it did that.
Misconfiguration can happen at any end of the tunnel.

Suggestion:
Change third paragraph to:

     Packets for which the IPv4 source address does not match MUST be
     discarded and an ICMP message MUST be generated, with the error code
     ICMPv4 Protocol 41 Unreachable.

Problem 8:
Section 3.6 Decapsulation

Unnecessary text in paragraph 4.

Suggestion:
Remove 4th paragraph.

Problem 9:
Section 3.6 Decapsulation

Text misplaced in middle of paragraph 5. Text makes no sense.

Suggestion:
Remove or clarify paragraph 5.

Problem 10:
Section 3.6 Decapsulation

Text needs more clarity in last enumeration in section.

    1)   if the tunnel is towards the Internet, the node should be
         configured to check that the site's IPv6 prefixes are not used
         as the source addresses, or

This is configuration in decapsulator? Decapsulation is ingress 
operation, while "towards" is related to egress operation.

    2)   if the tunnel is towards an edge network, the node should be
         configured to check that the source address belongs to that edge
         network.

This is configuration in decapsulator? Decapsulation is ingress 
operation, while "towards" is related to egress operation. How is 
belonging to an "edge" network determined?

Suggestion:
Clarify last enumeration in section 3.6.

Problem 11.
Section 5. Security Considerations

Text of first element in list of paragraph 4

Suggestion:

Change text

"IPv4 source address of the packet MUST be the same as configured for 
the tunnel end-point,"

to

"IPv4 source address of the packet MUST be the same as the tunnel 
entrypoint address configured in the tunnel exitpoint (decapsulator),"

Problem 12.
Section 5. Security Considerations

Last paragraph suggests mechanism that is black holing accidental 
miconfigurations of tunnels, giving no alternative mechanism to uncover 
the misconfiguration.

Suggestion:
Remove, or clarify

I hope this helps,
Alex

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Aug 2004 14:50:00 +0300 (EEST)

[...]

(I'll respond with only the document editor hat on.)

I'll try to summarize your issues in a different way (please clarify
if something is missing):

 A) you want to explicitly spell out that the encapsulator address is 
configured on the node, and sprinkle that information throughout the 
document. (Problem 1, part of problem 2, problem 3, problem 4, problem 
6, problem 11).  

Response: there are arguments against doing so, because it is not
necessary for protocol interoperability.  I want to see more support
from the WG if this would go in.  Erik Nordmark voiced support for the
initial versions offlist, but has been quiet since -- it is not clear
whether this is due to agreement (with either party) or not.

I will also note that none of the protocol problems you state seem
convincing: breaking IP frag, breaking ICMP, breaking dynamic MTU,
breaking point-to-point link appearance.  The first three are just
basic properties of IPv4 routing: if you insert wrong source address,
you don't get the return packets.  The last still holds but between
addresses, not the nodes (it might be possible to make this more
explicit with an editorial correction to the definition of a tunnel,
to set the right expectations).  The security problem is not a real
issue, because the attackers have easier time just sending the packets
using raw sockets or whatever, not by configuring a tunnel interface
-- this would create a false sense of security at best because you
just can't trust the encapsulators to behave well in any case.

 B) you want to spell out that the source address is used as a filter
for inbound packets (i.e., which tunnel they belong to), and that the
addresses MUST be the same on entry & exit points, (the rest of
problem 2)

Response: this is a clarification which is not required for protocol
interoperability.  Further, it may restrict the implementators of the
protocol.  It also adds a MUST for which an implementor has no way of
ensuring it's fulfilled (there is no way to check what the other end
has configured -- either it works or it doesn't) -- so this is an
unnecessary specification.

 C) you want to add a MUST to generate protocol-41 unreachables when 
you receive a packet with incorrect source address. (problem 7, 
problem 12)

Response: this has already been discussed. Please check the archives
at http://ops.ietf.org/lists/v6ops/v6ops.2003/ (scroll down to "RFC
2893 Question - Ingress Filtering of IPv6-in-IPv4").  There are good
reasons why no ICMP feedback is *required* (however, it's still
compliant to send one if you want, it's SHOULD NOT in the spec.).

 D) you'd like to see a couple of editorial changes (problem 5, 
problem 9, problem 10)

Response: 5 & 9 can be easily fixed at AUTH48.  I don't understand the
problem 10 at all as by definition all the tunnels are now
bidirectional.  If egress is towards X, ingress is coming from X.  
Wording suggestions are welcome if really necessary.

Summary:

Keeping in mind the current state of the document (past WG last call,
past IETF last call, past IESG evaluation), there is very strong
reason to make no changes unless there is a strong reason to do so.
I'll take editorial issues to the account (issue D), but unless there
is WG consensus, I will not incorporate other changes as they do not
seem to be sufficiently do not seem to fulfill the "very strong
reason" criterium.

(editor hat off)

---

From: Alex Conta <[email-masked]>
Date: Tue, 17 Aug 2004 23:56:46 -0400

As a clarifications:

I have no interest or benefit in blocking or delaying the publishing of 
this document as an RFC.

I have a definite interest in having a good quality document.

Quality is more of an issue than time.

I am not happy at all that I found these problems, I would have been a 
lot happier to find none.

I do not have a lot of time to spend on this, or debate this - I already 
spent a lot more time than I initially planned or hoped.

> if something is missing):

I have ordered the problem descriptions and suggestions in the order of 
the sections in the document to make them flow with the reading of the 
document.

I am not sure I understand the use of this new exercise, but with the 
hope it will help resolving the problems, here it is:

NOTE: A majority of the technical problems were described to you already 
by me or by Erik N. in the private Email exchange we had, in quite a bit 
of detail, so they should not be new to you.

> configured on the node, 

NO. I want a tunneling rule, and/or the previous specs rule, followed.

The tunneling rule is that the source address in a tunnel packet MUST be 
one of the encapsulator's addresses - see Problem 3 and 4.

This is captured in two rules:
Rule 1.
If the tunnel source address is selected automatically by the 
encapsulator, it MUST be one of the encapsulator's addresses, preferable 
the tunnel packets outgoing interfaces.

Rule 2.
If the tunnel source address is configured on the encapsulator, which is 
OK, it MUST follow the same rule as 1, that is, MUST be one of the 
encapsulator's addresses, preferable the tunnel packets outgoing interface.

> and sprinkle that information throughout the 

Please read carefully my message; it is not only sprinkling that info.

Problem 1, 2 are independent. Section 1.1 and Section 3 are incomplete, 
as they seem to be left as they were before the changes, and have not 
followed the changes that this document has undergone.

Problem 6 and 11 are both independent from each other, and from the 
rest. They're inadequate wording, and thus editorial. They're completely 
independent of anything else.

> whether this is due to agreement (with either party) or not.

Erik N. pointed out also a number of problems.

> breaking point-to-point link appearance.  

You had both me and Erik N. point to and explain these problems.
Here it is once more, this time for the list:

The spec suggests configuring the encapsulator with a source address 
which is not one of its addresses. This is a departure from the IP 
architecture, one of the basic functions of the IP, and has the 
following immediate consequences:

- broken virtual point-to-point link:

The tunnel is a virtual point-to-point link between the encapsulator and 
decapsulator. Tunnel packets originate on the encapsulator, and thus 
must have as source the outgoing interface address or one of its other 
addresses.

When the encapsulator sends packets with a source address which is not 
one of its interfaces, it breaks the vptop mechanism.

Also, if a node can be configured accidentally, or intentionally, with a 
tunnel source address different than its own addresses, it is possible 
to configure multiple encapsulators with the same source, but same
decapsulator. This is a non-traditional multi-point to point link, and 
thus different from the vptop, specified in this document.

To repeat Erik N.'s comment, if the source address is an anycast 
address, that MUST be said so, and dealt with it appropriately, and not 
just pushed under the rug.

- breaking ICMP.

If an intermediate router on the tunnel path detects an error in a 
tunnel packet that has a source address which is not one of the 
encapsulator's addresses, the ICMP message cannot reach the 
encapsulator, and the forwarding of the packet may have unpredictable 
results.

This may have unpredictable results.

- breaking dynamic MTU (problem pointed out by Erik N.)

If a tunnel packet has a source address different than one of the 
encapsulator's addresses, Path MTU ICMP messages cannot reach the 
encapsulator. This breaks the dynamic MTU mechanism.

- breaking IP fragmentation (problem pointed out by Erik N.)

If multiple encapsulators have the same source address, and there is 
fragmentation on each of them, the spec does not specify how to 
coordinate the IP fragment IDs, so the packet reassembly will not get 
confused on the decapsulator. This breaks IP fragmentation.

- other consequences may exist.

> The first three are just
> you don't get the return packets.  

This is missing the point.

The expectation is that when one follows correctly this protocol 
specification the result is a working IPv6inIPv4 tunnel.

In this case, one configuring an address that is not one of the 
encapsulator's addresses is following correctly the specification.
However the result is a non-working IPv6inIPv4 tunnel.

The last still holds but between
> to set the right expectations).  

A node has interfaces, which are the node's attachments to adjacent 
links. Addresses identify interfaces in the network. Point to point 
links are between ptop interfaces.

I am afraid, a new, technically different definition of a tunnel cannot 
be an editorial change.

The security problem is not a real
>  not by configuring a tunnel interface

The way you allow the configuring of the encapsulator is breaking the 
very mechanism that you created or existed in the decapsulator, which is 
checking the encapsulator's source address.

This creates exactly the very problem that it is mentioned in the 
Security section as a problem.

> just can't trust the encapsulators to behave well in any case.

I agree with that (false sense of security), but then why not remove the 
decapsulator source address check all together?

> addresses MUST be the same on entry & exit points, (the rest of

Problem 2 is simply insufficient text.

The changes done on this document on some text resulted in that text 
being removed, or moved in the wrong place. Consequently the 
specification has holes when compared to its predecessor, RFC 2893, and 
for a draft standard it MUST be corrected.

The suggestion is supposed to plug the holes.

> interoperability.  

This does not seem an accurate characterization.

Currently two IP implementations that are configured according to the 
spec, may not work, that is, they may not interoperate.

The suggestion spells out the configuration requirements, and helps the 
configuring, with the result of a working IPv6inIPv4 tunnel, which is to 
have two implementations interoperate.

In conclusion is that the suggestion resolves interoperability problems, 
and thus is required for interoperability.

> Further, it may restrict the implementators of the
> protocol. 

Rewording "restrict", with "driving in the right direction" would be 
more accurate.

  It also adds a MUST for which an implementor has no way of
> unnecessary specification.

The MUST is related to the configuring of addresses, not to 
implementation. This is also an operational spec isn't it?

> compliant to send one if you want, it's SHOULD NOT in the spec.).

I do not have the time to check the archives.

I simply pointed out, that currently there is a black hole effect.

That means, it is possible to have a legitimate configuring of a tunnel 
between two nodes, according to the spec, but a tunnel failure, with 
packets seemingly going nowhere, and have no indication of the reason 
the tunnel packets sent from one node do not get to the other.

Furthermore, having it both ways, /w and w/ ICMP messages seems  confusing.

> Wording suggestions are welcome if really necessary.

The text is confusing to the extent that I can have several correct but 
opposite interpretations.

I could work on this with you, but for that I need you qualify the 
nouns, and verbs in those sentences, so I can see what the spec (or you) 
really wanted to say.

> seem to be sufficiently do not seem to fulfill the "very strong

You had one person (me) and a previous co-author (Erik N.) pointing you 
these problems.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Aug 2004 02:22:54 -0700 (PDT)

>                   encapsulator's node addresses.

I think it makes sense to do this minor clarification since the current
text can be read as the protocol allowing the source address to be
configured to be the IPv4 address assigned to some other node.
This clearly doesn't work for many reasons such as ICMPv4 errors wouldn't be
sent back to the encapsulator.

However, I don't think we need to repeat that the tunnel source address can not
be an address not assigned to the node all over the document.

>      ICMPv4 Protocol 41 Unreachable.

I haven't read the followup emails on the list yet, but if this is
essentially a form of source address filtering, the fact is that for
ingress filtering there is no error message. So a MUST is definitely
too strong - there are good reasons for not sending any error. A MAY might
be appropriate [I have to read the rest of the messages on the list.]

Sending protocol 41 unreachable seems like a likely source of confusion
though so we shouldn't overload that.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Aug 2004 12:40:22 +0300 (EEST)

[...]
> sent back to the encapsulator.

My concern with this is that configuring such address (not assigned on 
the node) is essentially misconfiguration by the administrator of the 
node.

Should IETF protocol specifications be concerned of such kind of
misconfiguration?  There are a LOT of different ways the admins can
render the protocols inoperable by misconfiguring them badly....

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
relying that when the admin configures something, there must be a
reason for it. __And if the tunnel doesn't work, that's
administrator's problem due to misconfiguration, not the protocol's,
so it's arguable that the tunnel not working would be a feature, not a
bug__.

I just checked 4 different implementations: Linux, BSD, Cisco and
Juniper.  All of them "allow" the administrator to misconfigure the
source addresses.  This would seem like a hint that the implementors
want to give the power to the administrators, or not bother with
additional checks. I'd be interested if you know of implementations
which check the tunnel source address at configuration time?

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?

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Aug 2004 03:00:51 -0700 (PDT)

> the node) is essentially misconfiguration by the administrator of the 

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.

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

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

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.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Aug 2004 14:12:29 +0300 (EEST)

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

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

> address assigned to the node. So this sure sounds like a MUST as far as I can

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?

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Aug 2004 05:21:00 -0700 (PDT)

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

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.

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

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

> 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

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Fri, 20 Aug 2004 18:11:31 +0530

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" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Alex Conta" <[email-masked]>; <[email-masked]>
Sent: Friday, August 20, 2004 4:42 PM
Subject: Re: misconfiguring the tunnel source address [mech-v2-04]

> > I think we should ask ourselves what behavior would such a MUST exclude
that

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Aug 2004 15:45:29 +0300 (EEST)

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

> where a source address assigned to the node needs to be selected. So I think

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.
 
> and the tunnels isn't qualitatively any different than other ordering 

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.

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

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

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 20 Aug 2004 10:39:55 -0400

> which check the tunnel source address at configuration time?

Tru64 and maybe HP-UX do.

It seems like this problem is an artifact of uni-directional tunnels
that were present in rfc2893.  Since all tunnels now are bi-directional
point-to-point links, the additional specification may be a good idea.
This way, additional guidance is given to the implementors.

-vlad
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Linux and Open Source Lab
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Alex Conta <[email-masked]>
Date: Fri, 20 Aug 2004 14:48:32 -0400

> be an address not assigned to the node all over the document.

I agree.

Note though that Problem and Suggestions  1, 2, and some others, deal 
with the fact that with all the text that was removed from the RFC 2893, 
makes the text regarding configuring an address in Section 3.5 look like 
it comes from nowhere, without any supporting text anywhere else in the 
document. Earlier sections are supposed to create the support for 
Section 3.5., and so they are now incomplete, and the text in 3.5 looks 
like an orphan.

> though so we shouldn't overload that.

If configuring the decapsulator is a form of "ingress filtering" that is 
optional, and separate from then tunnel configuration, I have no problem 
at all, and my suggestion does not apply.

However, if configuring the decapsulator is part of configuring the 
tunnel, as one of mechanisms of the tunnel, then the situation changes.

It is not different from configuring a PVC on ATM or configuring a PPP 
link.

If there is some problem configuring such a PVC, or PPP, there is some 
sort of notification telling you that.

A tunnel misconfiguration notification of some form, that propagates to 
the operator is I think necessary and helpful.

Regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Fri, 20 Aug 2004 17:23:17 -0400

Pekka Savola wrote:

> [..] However, we've concluded that configuring the tunnel

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

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?

>>where a source address assigned to the node needs to be selected. So I think

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 

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.

> There he sees guidance that he can provide the source and destination 

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.

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

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

This is not acceptable...

Regards,
Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 Aug 2004 09:37:07 -0700 (PDT)

> then it's automatically determined.

Why is that obvious for the case of configured tunneling?
Especially given that we have other IETF specifications
that talk explicitly about using an IPv4 anycast
address as the source address of IPv6-in-IPv4 packets.

   Erik