[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mech-v2-05pre
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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Pekka Savola
> Sent: Monday, August 23, 2004 10:59 PM
> To: Alex Conta
> Cc: v6ops@ops.ietf.org
> 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
>
>