Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

[Pekka Savola <pekkas@netcore.fi>]

in-line... omitting the parts where we agree..

On Tue, 4 May 2004, Alain Durand wrote:
> On May 4, 2004, at 5:32 AM, Pekka Savola wrote:
> 
> >                                                                    The
> >    tunnel set-up protocol must support both modes, however ISP 
> > deploying
> >    it may choose to only support one mode of operation.
> >
> > ==> this should be probably be its own paragraph, but a more important
> > issue: is this a requirement for a) the protocol, or for b) the
> > implementation of the protocol, or c) its deployment?
> >
> > It looks like a) and c) but I could be wrong.
> 
> I would say a) and b). b) for interoperability reasons. While
> deploying it, you turn on or off any features you like or not.

You mean, that's the goal?  I agree.  (The text currently seems to say 
a + c).

> > My argument is that IMHO the simple mode should be a must for
> > implement, the registered mode a should; and whatever the
> > operators do is up to them, but we could recommend them to not
> > turn off the simple mode to keep it interoperable.
> 
> If the ISP deploy the 'registered' mode and it has not been
> implemented in the client, it does not work. That's why I think all
> implementations would have to support both and the operation mode
> would be decided by the ISP.

It would be beneficial to support both, yes, but if this was to be 
applied e.g., in 3GPP or mobile environments (just to take an 
example), I'd guess that there might be some interested in simplifying 
the client.

Similarly, as providing service over a tunnel is more or less a 
"tryout" service in any case (I don't think many ISPs would see that 
as "production"), my personal view is that the most who would want to 
deploy something like this in the first place would actually want the 
simple mode.  (And if they're OK with all the registration etc. 
_process_ and procedures, many could use L2TP or deploy dual-stack in 
any case.)

The simple form is also something that could be implemented and turned 
on by default on hosts (when v6 is turned on, if not on by default, 
that is).

That's why I think "simple" form is criticial, and the registered mode 
interesting for "power users" but not necessarily for all that many 
ISPs for production use.

> > 5.1. Address and Prefix Delegation
> >
> >    The authenticated mode must support delegation of a single address 
> > or
> >    a whole prefix or a combination of both.
> >
> > ==> again, I've said this in the past, but IMHO prefix + address
> > is not interesting.  This is definitely not a must or even a
> > should, IMHO -- and should be scrapped entirely.  I assume the
> > address would be assigned on the point-to-point address (and such
> > address is not even needed at all!).
> 
> This is again an operational decision that can be made only by the
> ISP. This is why, IMHO, the protocol and its implementations should
> support both modes.

Note that I'm not arguing for doing address assignment or prefix 
delegation, but I was just stating that doing _both_ for a single 
session (as it appears to read) does not seem like a useful 
requirement.

> >    note: not clear what should be the mandatory authentication method.
> >    Clear text password is out. Digest-MD5 [2831] seems like a good
> >    choice.
> >
> > ==> I don't have a strong opinion either, but Digest-MD5 is not
> > acceptable -- MD5 must not be used for new protocols due to its
> > collision weakness.  Use SHA1 instead.
> 
> Why not. is it an IESG policy?

Yes. draft-iesg-tcpmd5app-00.txt provides some background to this, but 
focuses on TCP-MD5 only.

> > 6.1 Scalability
> >
> >    The tunnel set-up protocol must be scalable.
> >
> > ==> We need a few more words than that to flesh out this requirement, I
> > think ;-)
> 
> really? ;-)

Good that we agree ;-)

[[clipping comments you agree with]]
> > ....
> >
> >  However, as
> >    NAT traversal usually requires an extra layer of encapsulation, the
> >    tunnel set-up protocol must be able to detect automatically the
> >    presence of one or more NAT boxes in the path.
> >
> > ==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO a
> > should is sensible.)
> 
> Not sure. I think the protocol and its implementation MUST
> support the detection, but the deployment MAY turn it off.
> i should clarify this.

This is a bit in odds with 4.3 and 5.3 then, as those seem to be 
closer to a 'should'.

My own view is that in some environments it might be acceptable to 
just always use UDP, to avoid certain hassles of toggling between 
proto-41 and UDP -- but as this causes overhead, we should try to 
avoid the overhead if feasible.  Hence a (strong) should.
 
> > ==> do we want to test for the presence of a proto-41 forwarding
> > NAT box? That would likely be complicated (would require extra
> > transmission of proto-41 packets)?  If we put that in, it's a
> > "may" at most.
> 
> I hadn't thought of that... Is it the case that if proto-41
> forwarding is in place then the communication would be
> un-differentiable from a non nated one?

It's slightly different: the "internal IP address" set in the packets 
to detect whether NAT was on the path or not would tell there is a 
NAT, and would result in (an unnecessary) fallback to UDP.

So, to cater for that situation, the logic would have to be like:

 1) send the packet to the server with "my own address" set
 2) the server notices that "my own address" and the source address 
    are not the same.
  2.1) the server tries to send an IP-proto-41 packet to the source 
       address in any case; if it doesn't hear back soon, retry with 
       UDP.
  2.2) failing that, just send the packet on UDP.

  2.3) in both cases, activate the NAT keepalive sequence.

It seems to me that the fallback in 2.1) might add some substantial
code in case the NAT doesn't forward proto-41, especially if the
negotiation/parameter exchange would otherwise conclude after sending
the packet (i.e., this would require at least 1.5 roundtrips to verify
a host behind a NAT got the information, and if it didn't, at least 2
roundtrips -- using just UDP could be done with 1 roundtrip.)

Obviously, this kind of "forwarder detection check" could possibly be 
implemented separately, and would be indicated as a flag from the 
client, but that might have some minor failure modes as well.

> > 6.5 Latency in Set-up Phases
> >
> >    In certain type of networks, keeping tunnels active all the time is
> >    not possible or simply too expensive.
> >
> > ==> maybe spell out an example here or later in this section, like:
> >
> >    not possible (e.g., when the host is mobile) ....
> 
> nothing to do with mobility but with the charging method (i.e. by
> the minute?). But I agree, more text is needed.

Yes, the text focused on the charging model, but section title on 
Set-up latency is important for mobile etc. as well, so it should be 
mentioned somehow.
 
> > 6.7 Traceability
> >
> > ==> this is not really traceability, reword; maybe like
> > "Provides Enough Information about Usage"
> 
> Is this not the definition of traceability?

I, at least, think of traceability as "a way to trace the usage of a 
user or IP address" which is a bit different?

> > ==> actually, this should probably be reworded as it's ambiguous.
> > Obviously, if the user sees a route advertisement on the native
> > link (or the like), that should be used instead.
> 
> No, this is not enough. Example: I may have a local router on my
> ethernet link that advertises an internal prefix, but this does not
> mean that I can use it to get external connectivity and have to give
> up my modem line.

OK -- what it could probably check is default route with medium 
or high preferece (and your case, one should use low preference or 
more specific routes).

> > But is it the ISP's business to "stop" the user to start using
> > native v6 instead (if it doesn't work automatically)?  At most,
> > the mechanism should provide a means to show the user a message
> > that ISP is also providing native v6 service (possible e.g. if the
> > user switched to new service class, or replaced the NAT box) even
> > though the user is not obtaining it at the moment.
> 
> Yes. This is the concern I have, ISP now offer native, but the box
> is still configured to use the tunnel.

Right.  But is it a good idea to "cancel" service like that?  I mean,
in most cases, it's fine if the user is able to (automatically!) get
v6 using other means -- but if it's not automatic, the user would be
left without service altogether!

In other words, the ISP can cease tunneling service by taking down the 
tunnel server or making sure it provides no further allocations if the 
ISP wants to be "draconian".  The most we should probably do is have a 
means for the client software to state that native v6 is available 
(whether mentioned by the server or not)..

> >    [3053] A. Durand, P. Fasano, I. Guardini, D. Lento.,
> >           "IPv6 Tunnel Broker", January 2001.
> >
> >    [ISP]  Lind, M., "Scenarios and Analysis for Introducing IPv6
> >           into ISP Networks",
> >           draft-ietf-v6ops-isp-scenarios-analysis-01 (work in
> >           progress), February 2004.
> >
> >    [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for
> >           Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work
> >           in progress), February 2004.
> >
> > ==> these probably belong ot the normative references section.
> 
> I never understand what goes where... What is you rationale?

Normative refs are usually those which must be read in order to
understand this particular document, or must be implemented in order
to implement this spec.

In this particular case, you seem to be citing at least [ISP] and 
[UNMANAGED] in such a way that this would seem warranted.  

(One feature of normative refs is that they block publication, but as
you cite the scenarios from those in a particular fashion, this
document should not go forward unless those scenarios and text are
final.)

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