Subject: RE: mech-v2-05pre

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Wed, 25 Aug 2004 09:42:00 +0200

Hi Pekka, Alex

Wrt the definition of the point-to-point link concept for IPv6  - then
RFC 2461, Section 2.2,  states:

  "point-to-point - a link that connects exactly two interfaces.  A
                    point-to-point link is assumed to have multicast
                    capability and have a link-local address."

When using the term "point-to-point links" in section 3.8 of mech-v2, 
I have always assumed the above definition to be the one referred to - ?

BR, Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Pekka Savola
> Sent: Monday, August 23, 2004 10:59 PM
> To: Alex Conta
> Cc: [email-masked]
> Subject: Re: mech-v2-05pre
> 
> 
> On Mon, 23 Aug 2004, Alex Conta wrote:
> > > It appears that there is at least some form of support of 
> clarifying
> > > the text to more clearly state that the tunnel entrypoint 
> should be an
> > > IPv4 address of the encapsulator. However, there are 
> reasons (e.g., as
> > > Stephen mentioned) why checking this at configuration 
> time might not
> > > be beneficial, and others also think this is an 
> implementation detail.  
> > 
> > Perhaps you have not read the last message Stephen sent on the 
> > discussion thread; as it turns out, the implementation 
> Stephen mentioned 
> > does perform an address check, on the completion of the interface 
> > configuration operation.
> 
> Yes, I did read it.  But because the check is made later in the
> process, after already configuring the tunnel (but rather when
> deciding whether it's feasible to being operationally enabled or not),
> it's entirely different issue -- which cannot be tackled without going
> in depth to the operational status issue which is IMHO something we
> should not do.  The point which was made that configuration-time
> checking has drawbacks, and that's one reason we don't want to
> recommend it, but leave it entirely up to the implementors.
>  
> > Importantly, because the tunnel is a virtual point-to-point link, 
> > checking the correct tunnel entry point address, if it is being 
> > configured, is primarily a "protocol issue", so it belongs 
> to the tunnel 
> > protocol engine, as opposed to the command used to 
> configure the tunnel.
> 
> I disagree with this.  This depends on what you define the 
> 'protocol'.  
> I define the protocol as a mechanism which runs between two IPv4
> configured addresses: whether it has a chance of working or not
> depends that the configuration information ("input function" if you
> consider the protocol as a system) has been entered correctly.
> 
> You probably think that it's protocol's job to deal with
> misconfiguration, and a BUG of the protocol if it doesn't; my
> assumption is that the protocol must work correctly with the correct
> configuration, and nothing more is required.
>  
> > The correct analogy between this type of tunnel and a TCP, 
> (or connected 
> > UDP) communication was made in some earlier messages, in 
> that the "bind" 
> > function call implementation, called when "binding" a TCP, (or UDP) 
> > socket to an address, checks that the address belongs to the node.
> 
> That is IMHO a bad analogy as I pointed out.  TCP and UDP are
> user-level protocols, requested by applications which have no specific
> rights or privileges.
> 
> Setting up tunnels *always* (AFAICS) requires special 
> "administrative"  
> privileges.  It's not meant to be used by regular users and apps in
> any way they feel fit.  Sure, if they're given sufficient permissions,
> they could set up tunnels, but it comes with the caveat that they must
> know what they're doing.
> 
> > Currently, the specification seem to suggest that the checking is a 
> > "configuration command issue", and that is false: it is a "protocol 
> > setup issue", with appropriate place to address in the 
> protocol setup 
> > mechanism.
> 
> As stated above, I disagree with this interpretation of the 
> protocol.  
> Protocols must not require being designed to work with incorrect input
> from the administrators.
> 
> > Remember, the protocol can be setup by using some commands 
> (CLI), but it 
> > can be setup also by calling directly function calls or 
> entry points in 
> > the "protocol setup code".
> 
> I fail to see the analogy.  If you don't use CLI (which is implicitly 
> assumed), it's an implementation issue to deal with the consequences, 
> i.e., appropriately define the checks to the function calls to make 
> the protocol work better even with wrong input.
>  
> > However, I am going to point out once more, that configuring a 
> > bi-directional IPv6inIPv4 tunnel, should align with 
> configuring other 
> > bi-directional tunnels (PPTP, L2TP, MPLS etc...), and other 
> links, or 
> > virtual links(PPP, ATM VC's, FR VC's,...) where the 
> configuring provides
> > an error notification mechanism in case misconfiguration prevents a 
> > correct establishing of the tunnel, or link.
> > 
> > This alignment is necessary not for appearance reasons, but 
> for sound 
> > design and operational reasons, which pointed the above mentioned 
> > protocols to implement such error notifications.
> 
> As noted offlist, these examples are not close to what this spec is 
> aiming to do.  This is intended for a very simple mechanism, 
> requiring 
> *manual* configuration.
>  
> > Another comment, which I consider important:
> > 
> > Orthogonal to the error notification, the introduction of 
> > bi-directionality without support of passing/negotiating 
> configuration 
> > information automatically between the two end nodes of the tunnel, 
> > similar to other bi-directional tunnels, links, or virtual links 
> > (mentioned in previous paragraph) leaves the protocol look 
> as incomplete 
> > ('half baked').
> 
> Again, such protocols can be specified and used in conjuction with
> this spec, to help set up the tunnels.  See for example TSP.  Or you
> could just use L2TP instead, that provides v6 support out of the box.
> 
> > Comment 1 (major)
> > -----------------
> > Page 4, Section 1.1, Configured Tunnels
> > 
> >          .... behaving as virtual point-to-point links
> >          between the IPv4 tunnel endpoint addresses.
> > 
> > Problem:
> > 
> > "virtual point-to-point links between ..addresses", 
> introduces a new and 
> > faulty concept.
> > 
> > IETF, and other standards bodies are very clear on these concepts:
> > 
> > - Point-to-point links are between two nodes
> 
> Please provide a pointer to such concept because I haven't heard of
> such consensus.  Point-to-point can be whatever we define it to be as
> long as the definition of "point" is clear, which is exactly what I
> was doing :-).
> 
> > - nodes are attached to links through interfaces
> > - addresses are identifiers of interfaces on the link, and network.
> > 
> > Suggestion:
> > 
> > replace "addresses", with "nodes", or
> > remove "addresses", and make "endpoint" plural, i.e. "endpoints".
> 
> No; the fundamental presumption of the current specification is to
> provide a tunnel between configured *addresses*, not *nodes* (which
> could have multiple addresses).  As the new security checks etc.  
> prevent the use of more than one address per node, we must spell out
> the assumption that we want p2p between addresses not the more generic
> p2p because it doesn't work.
> 
> > Comment 2
> > ----------
> > Page 8, Section 3., last paragraph, and all other occurances
> > 
> > ..... protocol-41, or protocol 41...
> > 
> > Problem: language
> > 
> > Suggestion:
> > replace "protocol-41", or "protocol 41" with
> > "IPv6 in IPv4 tunneling protocol"
> 
> This doesn't seem a good approach, because protocol 41 is very 
> specific.  There could be other v6-in-v4 tunneling protocols which 
> might not use protocol 41.  It's better IMHO to use protocol-41 which 
> is short and accurate (as far as it can be accurate).
>  
> > Comment 3
> > ----------
> > Page 15, Section 3.5
> > 
> >                  An IPv4 address of the encapsulator: 
> either manually
> >                  configured or an address of the outgoing interface
> > 
> > problem: language
> > 
> > Suggestion:
> > replace with:
> > 	
> >                  An IPv4 address of the encapsulator: manually
> >                  configured or automatically selected from 
> the addresses
> >                  of the outgoing interface
> 
> Could your suggestion be interpreted that the manually configured
> address must be an address of the outgoing interface?  That would be
> wrong, because it can be e.g., the loopback address.  I don't see how
> your suggestion clarifies.
>  
> > Comment 4
> > ----------
> > Page 15, Section 3.5, last paragraph
> > 
> > ... tunnel peer has configured...
> > 
> > also penultimate sentence of paragraph
> > 
> > Problem:language; the "tunnel peer" is the object of 
> configuration and 
> > not the agent performing the configuration.
> > 
> > Suggestion:
> > 
> > replace "has" with "was".
> > 
> > sentence is still awkward, and unclear. Replacing text was 
> suggested 
> > with earlier message.
> 
> I can't parse the sentence if I change "has" to "was" so I guess 
> you're reading it differently than I am.
> 
> Would it be clearer to just remove the text about tunnel peer (because
> it's now stated just before section 3.1) and change to singular for
> clarity, like:
> 
>    When encapsulating the packets, the node must ensure that it will
>    use the correct source address so that the packets are 
>    acceptable to the decapsulator as described in Section 3.6. [...]
>  
> > Comment 5
> > ----------
> > Page 21, Section 5.
> > 
> >      -   IPv4 source address of the packet MUST be the same 
> as configured
> >          for the tunnel end-point,
> > 
> > problem: ambiguity in text; as it is a bi-directional 
> tunnel, the tunnel 
> > end-point is configured with a reverse path tunnel, i.e. a source 
> > address, which is one of the decapsulator's addresses. Without 
> > qualifiers, "configured" can be understood as applying to several 
> > things, in which "source address" is different.
> > 
> > Suggestion:
> > replace with:
> > "IPv4 source address of the packet MUST be the same as the tunnel 
> > entrypoint address configured for filtering purpose in the tunnel 
> > exitpoint (decapsulator)
> 
> I've wanted to avoid introducing the entry/exit point 
> terminology, and 
> I don't want to say that the entrypoint is just configured for 
> filtering purpose; it's dually configured for the purposes of sending 
> packets to that address, so I don't think it needs to be said here.
> 
> Further, these bullets are just referring & summarizing the checks
> earlier in the draft, so I don't want expand it a lot here, rather
> just include a referring pointer if really necessary.
> 
> Would adding a referral to section 3.6 help, like replace:
> 
>    Therefore, this memo specifies that the decapsulators make these
>    steps to mitigate this threat:
> 
> with:
> 
>    Therefore, this memo specifies that the decapsulators make these
>    steps (described in Section 3.6) to mitigate this threat:
> 
> .. or some other smaller change?
> 
> Thanks!
> 
> -- 
> 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: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2004 11:03:02 +0300 (EEST)

> I have always assumed the above definition to be the one referred to - ?

Yes, that's how sect 3.8 uses Neighbor Discovery. I don't see a
conflict.  The goal of that definition is to define point-to-point for
higher layers.  We want to give a clear statement on what the
point-to-point is from the perspective of the lower layers.

The quote says p2p connects two interfaces.  That's OK, but that
refers (in this case) to the logical IPv6 tunnel interfaces, not the
physical underlying interfaces which are not necessarily even
IPv6-capable.

What we want to say is that the v6 link is a virtual point-to-point as
defined in above, and the lower layer endpoints of that p2p link are
the v4 addresses which are configured on the endpoint nodes' physical
interfaces. [and specifically, the lower layer endpoints aren't just 
any addresses on the endpoint nodes, rather the specific v4 addresses]

But that seems way too confusing way to put it, so just saying
"virtual p2p between v4 addresses" seems shorter and sufficiently
clear.