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

From: Dave Thaler <[email-masked]>
Date: Mon, 10 Nov 2008 18:37:08 -0800

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.

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.

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

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.

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.

-Dave Thaler

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

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2008 10:02:38 -0800

Olaf Maennel writes:
[...]
> 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.

That doesn't work for unmodified end-hosts.  The bottom of page 6 states:

> As we do not wish to modify end hosts , we expect customers to send
> IPv4 packets from any port(s).

As noted in my comment 3, modifying end hosts in general causes application
and/or user confusion problems.

> >                                      +----------+ CPE +---...ISP
> >               +----+                 |          +-----+
> See above. Basically our idea was that the CPE would allocate
> sub-port-ranges.

You missed the point.  I said above "assume the hosts are unmodified"
in this example.  Above you stated:

> 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

Hence in the example above, both the AP and the CPE are like a NAT
for H1 and H2.  However, AP gets a sub-port range from the CPE
since they're both A+P aware.  This means that the AP's address is
not on the subnet seen by H2.  Since H2 does not see the AP as being
on-subnet it won't ARP for the address.  It's not obvious how it
works in this case... is the CPE supposed to send a redirect?
Similarly when H1 sends a packet to H2, does the AP forward it to
the CPE or does it somehow know that H2 is onlink?

[...]

-Dave

---

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

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]]
> Sent: Dienstag, 11. November 2008 19:03
> To: Olaf Maennel
> Cc: [email-masked]; Randy Bush; Luca Cittadini; [email-masked]
> Subject: RE: Comments on draft-ymbk-aplusp-01
> 
> Olaf Maennel writes:
> [...]
> As noted in my comment 3, modifying end hosts in general causes
> application and/or user confusion problems.

Yes, no need to modify any end-hosts... Of course, the approach is
designed to work without any modifications to end-hosts. The A+P-gateway
is basically the NAT box. 

However, the question i had was the following: the original design of
the Internet had an end-to-end paradigm, is it still worth sticking to
that paradigm?  I personally think so. And my claim would be its
possible to come this goal a tiny bit closer, if we allow stackable
A+P-gateways. 
That's all. 
 
> > > 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
> for H1 and H2.  

You are right, i was not very precise there: i should have said A+P
gateway, not CPE. The CPE is just one possibility that can provide A+P
functionally. 

> However, AP gets a sub-port range from the CPE

Ah, i think i see the point of our misunderstanding. The closest A+P
device for the host is doing the NAT, and encapsulates in IPv6. For H2
the CPE is providing a private IPv4 address (rfc1918). On the other
hand, your access point AP has two interfaces: one towards the CPE, and
one to H1. H1 is behind the NAT of the AP (not the CPE!). For H1 AP is
doing the encapsulation in ipv6. Hence, the CPE only sees IPv6 packets.
However, the CPE knows which section of the available address space (or
should i better say port-range) is available, and which section is
sub-allocated to AP. AP might have just 'requested' 5 ports? Thus, the
CPE would do the NAT/encap for H2. 

Note: there is never an 'A+P packet' on the wire. On the WAN-side it is
in-v6-encapsulated and on the internal side it is NATed (e.g., private
IP address space a la RFC 1918). In this sense the A+P gateway is an
integrated service function that is doing everything. The A+P device
(besides the BR) is the only device that needs to know about A+P and the
only device that keeps state. 

Does this make sense? 

	olaf

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2008 12:52:31 -0800

Olaf Maennel writes:
[...]
> > > customer gets a private IP behind the CPE NAT box, and everything
> is
> as
> one to H1. H1 is behind the NAT of the AP (not the CPE!).

Yep, that matches my understanding, all good so far.

> For H1 AP is

Ok so if I follow this then the sequence from H1->H2 is, where 1.1.1.1
is the IPv4 address obtained from the ISP (possibly with some restricted
port range):
1) H1 sends IPv4 packet:
      IPv4 Src 192.168.0.100 port 100 (for example)
      IPv4 Dst 192.168.1.2   port 200 (for example)
   This matches H1's default IPv4 route and hence is sent to the AP.

2) Since the packet doesn't come from 1.1.1.1, the AP first NAT's the
packet's source to be 1.1.1.1 port (say) 4096 being a port in the sub-range
it got.  At this point we have
      IPv4 Src 1.1.1.1       port 4096
      IPv4 Dst 192.168.1.2   port 200

The doc then says in section 3.1:
> The CPE/CN receives an IPv4 packet
> from the end-user device to a destination address V4D. If private
> IPv4 address space [RFC1918] is used it NATs.  If the packet already
> originated from the assigned IPv4 address, it ensures that the source
> port falls into the allocated port range, and then encapsulates the
> packet in an IPv6 packet where the source address is WKP+A+P, and the
> destination address is WKP+V4D.

The text above says that encapsulation only happens if the source
port already fell into the allocated range (which it doesn't and it
had to NAT as stated in the quoted text).

The IPv4 packet would then match the AP's default route and be forwarded
to the CPE, which presumably would have to deal with this case and
send a redirect or support hairpinning or whatever else, hence my question.
I think this is what you mean, but my point is that the doc doesn't
explain what is supposed to happen here or even that this case can exist.

In your email response above where you said:
> For H1 AP is
> doing the encapsulation in ipv6. Hence, the CPE only sees IPv6 packets
you seemed to indicate that it would instead be
encapsulated in IPv6 after being NAT'ed.  I don't follow how this works
either.... following the logic in 3.1 for tunneling, the AP encapsulates
it in an IPv6 packet, with
      IPv6 Src 4999:0:0:0:0101:0101:1000::
      IPv6 Dst 4999:0:0:0:192.168.1.2::
Correct?  This matches the AP's default IPv6 route and hence is sent
to the CPE.

3) The CPE receives the IPv6 packet on its internal interface.
However instead of knowing to decapsulate because the destination
falls into the range 4999:0:0:0:0101:0101:<port range at CPE>
it would instead have to know to decapsulate if the destination
falls into the range 4999:0:0:0:192.168.1... (where 192.168.1/24
is the private space it gives to devices like H2).  If this is
what you meant, then there's still a bunch missing from the doc.

Similarly, in the reverse direction:

1) H1 sends IPv4 packet in response:
      IPv4 Src 192.168.1.2   port 200
      IPv4 Dst 1.1.1.1       port 4096
   This matches H1's default IPv4 route and hence is sent to the CPE.

2) The CPE gets this packet and since it's an IPv4 packet destined to
a port in its range, it knows it has to do something with it, but it
arrived over IPv4, not via IPv6 across its WAN side.  There's nothing
in the spec that says what to do here.

> only device that keeps state.

In the diagram above, the "WAN-side" from the (A+P capable) AP's
perspective is inside the home.

-Dave

---

From: <[email-masked]>
Date: Tue, 11 Nov 2008 23:49:17 +0100

> Sent: Dienstag, 11. November 2008 21:53
> To: Maennel, Olaf
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

Ah, your problem is that routing within "someone's home" does not work
on single WKP. Now i understand, sorry. That is absolutely true. So
either we have to remove the possibility to have stackable A+P-gateways;
or we cannot route on a single WKP between those stacked devices. Very
good point!

Thanks for that feedback!

	olaf

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2008 17:02:16 -0800

> From: Luca Cittadini [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2008 3:35 PM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]; [email-masked];
> Subject: Re: Comments on draft-ymbk-aplusp-01
>
> On Tuesday 11 November 2008 21:52:31 Dave Thaler wrote:
> That's a very good point.
> My conclusion is that an A+P gateway cannot NAT and/or encapsulate
> blindly,
> otherwise you lose the capability of routing v4 packets within the
> private
> domain. The A+P gateway should search its v4 routing table before
> modifying
> the packet: if its v4 RT (which supposedly contains correct entries for
> the
> private domain and no default route) contains a matching entry, the
> packet
> should be routed on v4, unmodified.
>
> In the example above, assuming that AP knows about the existence of
> 192.168.1.0/24 (e.g., the CPE has given 192.168.1.1 via DHCP), AP looks

In the current spec it says that AP would get a public IP (1.1.1.1)
with a sub-range of ports, since it's A+P aware, not a full private IP
which is what it would get if it's not A+P aware.

To both get a public IP (which means UPnP between H1 and the AP
would actually work fine to get a public IP+port, so this is a good
thing), and know about the existence of 192.168.1.0/24 then you
need to do something like RFC 3442 (there's a section on Local
Subnet Routes) so that the AP can learn this extra route from the CPE.

Another option that I mentioned earlier is that when the AP forwards
packets to the CPE destined to H2, the CPE has to send redirects so
that subsequent packets can flow directly from the CPE to H2.

Whichever approach you go with, the document should be updated.

-Dave

> in
> its v4 RT. Since it finds a matching entry, it does not touch the
> packet at
> all, and uses v4 routing. On the other hand, packets directed to
> the "external" domain do not have a matching v4 entry in the RT and are
> then
> NATted (if from wrong ip/port-range) and encapsulated.
> For "internal" IPv6 routing the anomaly should not arise, given that
> IPv6
> packets are never touched.
>
> Does this make any sense?
>
> Luca

---

From: Luca Cittadini <[email-masked]>
Date: Wed, 12 Nov 2008 00:35:24 +0100

That's a very good point.
My conclusion is that an A+P gateway cannot NAT and/or encapsulate blindly, 
otherwise you lose the capability of routing v4 packets within the private 
domain. The A+P gateway should search its v4 routing table before modifying 
the packet: if its v4 RT (which supposedly contains correct entries for the 
private domain and no default route) contains a matching entry, the packet 
should be routed on v4, unmodified.

In the example above, assuming that AP knows about the existence of 
192.168.1.0/24 (e.g., the CPE has given 192.168.1.1 via DHCP), AP looks in 
its v4 RT. Since it finds a matching entry, it does not touch the packet at 
all, and uses v4 routing. On the other hand, packets directed to 
the "external" domain do not have a matching v4 entry in the RT and are then 
NATted (if from wrong ip/port-range) and encapsulated. 
For "internal" IPv6 routing the anomaly should not arise, given that IPv6 
packets are never touched.

Luca