Subject: Re: [BEHAVE] Comments on draft-ymbk-aplusp-01

From: <[email-masked]>
Date: Tue, 11 Nov 2008 10:45:31 +0100

Dave, thanks a lot for all your comments!
 
On 11/11/08 3:37 AM, "Dave Thaler" <[email-masked]>
wrote:
> Overall, I like this approach, for restricted cases, which I'll get to
> under comment 3 below.  And I particularly liked section 2.2's
discussion
> of requirements.
>
> Will send a bunch of editorial feedback to the authors in separate
email.
>
> Some technical comments:
>
> 1) A bunch of places in the draft seem to only assume the existence of
a
> single host behind the CPE, which is not true in general.  For
example,
> page 8:
>
>> The A+P gateway should automatically translate any packet
>> that does not come from the proper port range (Constraint 1).
>
> This is close but it needs one very important correction.  It has to
come
> from both the proper port range AND the proper IP address.  Otherwise
you
> have collisions when two internal IP addresses try to use the same
port.
> Since there can be multiple hosts attached, you have to support
multiple
> (private) IP addresses inside.
>
> The example in Figure 2 is another case where it assumes only one
host,
> and having more than one (unmodified) host would break, unless I'm
missing
> something.

This is true and, admitted, this is not clear in the draft yet.
Basically we
envisioned two modes of operation: one traditional NAT-like behavior.
The
customer gets a private IP behind the CPE NAT box, and everything is as
transparent as today and done by a traditional-NAT. This is default
behavior.
 
However, A+P was supposed to extend routing and we thought we should at
least discuss the possibility of providing an end-host behind the CPE
gateway with a "public IP" (though port restricted). This would allow,
if
desired by the user, to reestablish end-to-end connectivity. In this
case
the CPE would have to allocate sub-port-ranges to the individual devices
on
the level below. We tried to discuss this in section 2.3. While this
gives
us end-to-end connectivity, this involves also some communication of
A+P-capability one level up. Admitted, we say that hidden and not very
clear
at the end of 2.3.:
>> One open issue for future
>> work is the choice of mechanism to sub-assign multiple parallel A+P
>> gateways.  For the moment, assume that the CPE allocates sub-port
>> ranges to subsequent end-devices.

> 2) Re section 2.3, an issue which is not addressed in this document is
how
> double A+P gateways inside a home (say, one in the CPE and another in
a
> wireless AP) work.  Consider this topology:
>
>                    +----+ 192.168.1.2
>                    | H2 +-----------------+
>                    +----+                 |          +-----+
>                                           +----------+ CPE +---... ISP
>                    +----+                 |          +-----+
>                 ((-+ AP +-----------------+
> +----+             +----+
> | H1 +-))
> +----+ 192.168.0.100
>
> Assume both the CPE and the AP are A+P-aware and the hosts are
unmodified
> hosts.  Since the hosts don't understand port restrictions both have
> to act as a NAT as far as the hosts are concerned (provide them a
> port-unrestricted private IP address).  Can H1 and H2 communicate
> with each other?  If so, how?  The rules in 2.3 are not sufficient
> to allow this case to work.
 
See above. Basically our idea was that the CPE would allocate
sub-port-ranges.
 
> 3) Re end-hosts supporting port-restricted IPs:
>> enabling an A+P-gateway on an
>> end-system could be as easy as installing a "kernel-patch".
>
> It's not that easy.  On a normal end user system you have to deal with
> either:
> a)      All the applications that make assumptions that a port-range 
> restriction
>       violates, or
> b)    Install a virtual NAT in the host, and then deal with the user
> confusion
>      issues in UI/management tools regarding why the physical
interface no
>       longer shows up to applications and some other virtual thing
does.
>
> Another reason to not have hosts to do A+P, only routers (NATs), is to
> preserve the assumption that from the host's perspective, the v4
subnet
> and the v6 subnet cover the same topological area.  This is never 
> required, but it causes user and/or app confusion when it isn't true 
> and so is good to minimize.
>
> For CPEs and fixed-function devices, the above are fairly easy /
> negligible, and I think this draft does a good job for such devices.  
> For a general purpose end host, they're very complex.  So using A+P 
> in a NAT seems good, whereas allowing an arbitrary host to do it is 
> actually quite difficult. It would be simplest to just say it may not 
> be applicable to general purpose hosts (or perhaps left for future
work).

That is a very good point. Thanks, we will reword this part.
 
The sole reason for this was again a consequence of showing that
end-to-end
connectivity could work as well. Actually, we thought about it a bit
more
differently (and again this needs to be communicated better in future
versions of the draft, if we would decide that end-to-end is still a
design-principle of the Internet):  Recall that we use
in-ipv6-encapsulation
for transport. Thus, end-hosts get native ipv6. A+P devices are
"stackable",
so anyone -even an application- could ask for an A+P port. It then
doesn't
really matter anymore if its an host or, as in this example, an
application
that would have to implement A+P-capability. Lets assume an application
would be A+P-aware. As it does ipv6-encapsulation, the packet would
"just"
be a native ipv6 packet to all other devices (including the host), and
pass-though everything unmodified. At the BR the packet is decapsulated
and
we have an IPv4 packet.
 
Ah, and i should emphasize again, that this is entirely optional. Our
basic
assumption was "no modifications to end-hosts". Thus, the CPE takes care
of
everything... (or in other words: private IPs behind the CPE).
Stackable
A+P devices are optional. Our only point was to show that it could be
possible to operate stacked A+P devices and thus get many other
benefits.
 
> 4) Re fragment handling:
>
>> If it runs out of space,
>> perhaps because of a resource exhaustion attack, it can always
>> discard older fragments.
>
> Same comment as on draft-gont-behave-nat-security-01...
>
> Simply discarding the oldest fragment just opens another attack
vector.
> If your incoming rate of new fragment ids is high enough (which an
> attacker could do), you'll never be able to complete any packet if you
> toss the oldest one first, since you'd be discarding stuff just before

> you get the last piece you need.

Very good point. Thanks.
 
>
> 5) General comment... the encapsulation/routing/whatever mechanism is
> largely orthogonal to the rest of the draft.  It could be factored
into 
> two sections or even two documents, one for the encapsulation/routing
> portion (which could be over IPv6 or MPLS or source routed or whatever
> else, and is more within the scope of Softwires) vs the port range
> restriction and translation aspects (which are more Behave scoped).  
> I do like the choice of IPv6 as the encapsulation medium though and 
> the way you use it to answer the incentive issue I mentioned in my 
> comments on draft-bajko-v6ops-port-restricted-ipaddr-assign.

Well, in theory A+P could run over all different kinds of
encapsulation/routing/whatever-layers. However, if we would decide this
end-to-end paradigm of the Internet is desirable, then all we need is
that
A+P devices are "stackable" (e.g., they work without problem in
sequence).
And we run into all sorts of problems if we don't encapsulate in ipv6 -
while in-ipv6-encapuslation would give us routing for fee, and also
avoid
double-NATs, etc...
 
Thanks for your feedback,
 
     olaf

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave