Subject: [BEHAVE] AD evaluation of draft-ietf-behave-v6v4-xlate-stateful-09

From: Magnus Westerlund <[email-masked]>
Date: Sat, 20 Mar 2010 08:06:15 -0700

Authors and WG,

As one of my last acts as AD I have performed an AD review of the
translator documents. As you have seen David is also reviewing the
documents in parallel as preparations for taking over the handling of
these documents. I am very pleased that the WG has managed to progress
these documents without to much delay.

See below my AD comments and questions from this review. As usual please
discuss things with me as it is as likely that I have misunderstood as
there are issues with the document. I also have to state that I have
failed to keep abreast on all the postings on the mailing list.

I do hope that these comments can be addressed quickly and if anyone
needs more discussion that we can identified that prior the IETF week is
over and take it in the BEHAVE session. However, please submit a new
draft as soon as you are able to. It is possible to submit new versions
from Monday of the IETF week.

1. Section 1:
"The
   IPv6 addresses of IPv6 hosts are translated to and from IPv4
   addresses by installing mappings in the normal NAT manner."

I think you mean NAPT manner here.

2. Section 1.2.1:
   The IPv4 address pool is a set of IPv4 addresses, normally a small
   prefix assigned by the local administrator.  Since IPv4 address space
   is a scarce resource, the IPv4 address pool is small and typically
   not sufficient to establish permanent one-to-one mappings with IPv6
   addresses.  So, except for the static/manually created ones, mappings
   using the IPv4 address pool will be created and released dynamically.
   Moreover, because of the IPv4 address scarcity, the usual practice
   for NAT64 is likely to be the binding of IPv6 transport addresses
   into IPv4 transport addresses, instead of IPv6 addresses into IPv4
   addresses directly, enabling a higher utilization of the limited IPv4
   address pool.

Also in this paragraph it is probably good making it clear that one are
doing address and port translation.

3. Section 2:

   Session:  A TCP, UDP or ICMP Query session.  In other words, the bi-
      directional flow of packets between two different hosts.  In
      NAT64, typically one host is an IPv4 host, and the other one is an
      IPv6 host.  However, due to hairpinning, both hosts might be IPv6
      hosts.

For UDP flow it doesn't need to be bi-directional. After all it is
possible to have a unidirectional flow from v6->v4. And RTP/UDP is a
good example where this might happen. The application can even know that
it working by having another bidirectional flow reporting on this
unidirectional one, like RTCP/UDP.

4. Section 3:
   The notation used is the following: upper case letters are IPv4
   addresses; upper case letters with a prime(') are IPv6 addresses;
   lower case letters are ports; prefixes of length n are indicated by
   "P::/n", mappings are indicated as "(X,x) <--> (Y',y)".

Are P::/n used also for IPv4? I don't think so but the text indicate
that one should use :: also for v4.

5. Section 3.1: This is trully nitpicking
A given IPv6 or IPv4 transport
   address can appear in at most one entry in a BIB: for example, (2001:
   db8::17, 4) can appear in at most one TCP and at most one UDP BIB
   entry.

Not that it is wrong to use port 4, but maybe the example would be
clearer if one uses a common port, like 80 or take one that nummerical
is beyond the what an address component can have, like one in the
dynamic range, e.g. 49832.

6. Section 3.2,
   The terminology used for the session table entry columns is from the
   perspective of an incoming IPv6 packet being translated into an
   outgoing IPv4 packet.

I think it would be better to move this paragraph prior to the list of
the different components. I was also thinking if it would be clearer if
one use like v6 external and v6 local and v4 local and v4 external
instead of source and destination. With local being from the NAT64's
perspective. But, I am not certain.

7. Section 3.5:
   Irrespective of the transport protocol used, the NAT64 MUST silently
   discard all incoming IPv6 packets containing a source address that
   contains the Pref64::/n.

What about the translatable range? Yes, I guess packets originating from
the range of translatable v6 addresses should go to the stateless
translator and not in the stateful. Are it worth clarifying this?

This also applies to the last sentence in Section 5.4.

8. Section 3.5.1
Lifetime: a timer that tracks the remaining lifetime of the TCP
      session.

A copy paste error, please change TCP to UDP here.

9. Section 3.5.2.1:
   TCP sessions are expensive, because their inactivity lifetime is set
   to at least 2 hours and 4 min (as per [RFC5382]), so it is important
   that each TCP session table entry corresponds to an existent TCP
   session.

I am not certain that expensive is the right word here. Compared to UDP
when packets are flowing I don't see the real difference. Yes, it will
tie up entries in the BIB and session table, but that is necessarily not
expensive. instead of "are expensive" maybe "can require BIB and Session
Table state for longer times than UDP"

10. Section 3.5.2.1:
      V6 SYN RCV: An IPv6 packet containing a TCP SYN was received by
      the NAT64, implying that a TCP connection is being initiated from
      the IPv6 side.  The NAT64 is now waiting for a matching IPv4
      packet containing the TCP SYN in the opposite direction.

I am missing a statement that the v6 syn has been translated into v4 and
forwarded. I think this is important as that is not happening in the v4
syn RCV case.

11. Section 3.5.2.1:

      4MIN: The lifetime of the state for the connection is set to 4
      minutes either because a packet containing a TCP RST was received
      by the NAT64 for this connection or simply because the lifetime of
      the connection has decreased and there are only 4 minutes left.
      The NAT64 will keep the state for the connection for a short time
      and if no other data packets for that connection are received, the
      state for this connection is then terminated.

What is a short time in the above text? 4 min, in that case write 4 min.

12. Section 3.5.2.2: closed:
      If the destination transport address contained in the incoming V4
      SYN (i.e., X,x) is not in use in the TCP BIB, then:

         The NAT64 tries to create a new session table entry in the TCP
         session table (if resources and policy permit), containing the
         following information:

So do I understand the above text correct is that the response to
receiving a v4 syn when the NAT64 has no BIB entry is to create only a
session state entry that isn't related to any BIB entry.

13. Section 3.5.2.2, v6 syn RCV

   For any other packet, other packets SHOULD be translated and
   forwarded if the security policy allows to do so.  The state remains
   unchanged.

I think there is worth having explicit text on what to do if a new v6
SYN packet is received. To me that would be translate and forward and
reset the timer.

14. Section 3.5.2.2, Established:

   If the lifetime expires then the NAT64 SHOULD send a probe packet (as
   defined next) to at least one of the endpoints of the TCP connection.
   The probe packet is a TCP segment for the connection with no data.
   The sequence number and the acknowledgment number are set to zero.
   All flags but the ACK flag are reset.

      Upon the reception of this probe packet, the endpoint will reply
      with an ACK containing the expected sequence number for that
      connection.  It should be noted that, for an active connection,
      each of these probe packets will generate one packet from each end
      involved in the connection, since the reply of the first point to
      the probe packet will generate a reply from the other endpoint.

   The state is moved to 4MIN.

Can you please move this last sentence into the above text. Currently is
looks like it applies to all the proceeding text.

15. Section 3.5.2.2, 4min:

   If a packet other than a RST packet is received, the lifetime of the
   TCP session table entry is set to at least to the maximum session
   lifetime.

So even a genuine reset (that is being honored) that has been reordered
with a regular packet will cause the state to hang around 4 hours.

Also, are there any directionality difference here for the packet that
sets the state back to Established?

16. Section 3.5.3:
An incoming ICMPv4 Query packet with source IPv4 address Y,
   destination IPv4 address X and ICMPv4 Identifier I2 is processed as
   follows:

What is the definition of an ICMPv4 Query packet? RFC 792 does not
contain the word query.

17. Section 3.5.3:
I seem to fail to find any discussion in this section about
reply/response ICMP messages.

18. Section 5.2:
In accordance with the procedures defined in this
   document following the guidelines defined in [RFC4787] a NAT64 must
   offer "Endpoint-Independent Filtering".

Based on the following text, aren't you talking about end-point
independent mapping here?

Thus also the below 3 cases needs to be fixed.

      Without filtering - When "Endpoint-Independent Filtering" is used
                                                     ^^^^^^^^^^
      in NAT64, once a binding is created in the IPv6 ---> IPv4
      direction, packets from any node on the IPv4 side destined to the
      IPv6 transport address will traverse the NAT64 gateway and be
      forwarded to the IPv6 transport address that created the binding.
      However,

      With filtering - When "Endpoint-Independent Filtering" is used in
                                                  ^^^^^^^^
      NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
      packets from any node on the IPv4 side destined to the IPv6
      transport address will first be processed against the filtering
      rules.  If the source IPv4 address is permitted, the packets will
      be forwarded to the IPv6 transport address.  If the source IPv4
      address is explicitly denied -- or the default policy is to deny
      all addresses not explicitly permitted -- then the packet will be
      discarded.  A dynamic filter may be employed where by the filter
      will only allow packets from the IPv4 address to which the
      original packet that created the binding was sent.  This means
      that only the IPv4 addresses to which the IPv6 host has initiated
      connections will be able to reach the IPv6 transport address, and
      no others.  This essentially narrows the effective operation of
      the NAT64 device to an "Address-Dependent Filtering" behavior,
                                                ^^^^^^^^^^
      though not by its mapping behavior, but instead by its filtering
      behavior.

19. Section 5.3:
This attack can only be launched from the IPv6 side,
   since IPv4 packets are not used to create binding state.

What are the implications of the saving in the session table for TCP
SYNs arriving on the v4 side? Yes, it doesn't consume a BIB resource,
however can the NAT64 device be DoS from a session table point of view?

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 25 Mar 2010 01:51:42 +0100

Hi Magnus,

thanks for the review, see replies below...

> I think you mean NAPT manner here.

fixed

> doing address and port translation.
clarified that by adding the last sentence, resulting in the following 
paragraph

<t>The IPv4 address pool is a set of IPv4 addresses,
        normally a small prefix assigned by the local administrator. 
Since IPv4
         address space is a scarce resource, the IPv4 address pool is 
small and
         typically not sufficient to establish permanent one-to-one 
mappings with IPv6
        addresses. So, except for the static/manually created ones,
        mappings using the IPv4 address pool will be created
        and released dynamically. Moreover, because of the IPv4 address
        scarcity, the usual practice for NAT64 is likely to be the 
binding of
        IPv6 transport addresses into IPv4 transport addresses, instead of
        IPv6 addresses into IPv4 addresses directly, enabling a higher
        utilization of the limited IPv4 address pool. This implies that
        NAT64 performs both address and port translation.

> unidirectional one, like RTCP/UDP.
ok, i have removed the bidirectional word out of the definition, 
resulting in

>     "P::/n", mappings are indicated as "(X,x)<-->  (Y',y)".
>
rephrased as "IPv6 prefixes are indicated by "P::/n"

> dynamic range, e.g. 49832.
ok, used the 49832 port
> the different components.

done
>   I was also thinking if it would be clearer if

i don't think that would be apropriate, cause because in nat64, any side 
can be external depending on the use case.
> translator and not in the stateful. Are it worth clarifying this?

but the Pref64::/n used by the nat64 will be a different one than the 
one used for stateless, right?
I mean, the routing must be configured so that all Pref64::/n traffic is 
sinked to the NAT64 box, so it doesn't seem a simple routing approahc to 
actually assign addresses out of this prefix to links in the local IPv6 
network, right?
> A copy paste error, please change TCP to UDP here.
fixed
> Table state for longer times than UDP"
mmm, is simply removed the characterization and rephrased as:

<t>Because the TCP session inactivity lifetime is set to at least
                 2 hours and 4 min (as per <xref 
target="RFC5382"></xref>), it is important that each TCP session table 
entry
                 corresponds to an existent TCP session.

> forwarded.

Ok, i have added that the packet was tranlsated and forwarded

>   I think this is important as that is not happening in the v4
> syn RCV case.
>
> 11. Section 3.5.2.1:
>
done

> session state entry that isn't related to any BIB entry.

correct
The reason for that is described in the end of the bulleted list

  The motivation for creating the session table entry and storing the 
packet (instead of simply dropping the packet based on the filtering) is 
to support simultaneous open of TCP connections.

> SYN packet is received. To me that would be translate and forward and

done
> looks like it applies to all the proceeding text.
done

> with a regular packet will cause the state to hang around 4 hours.
right

> sets the state back to Established?
we discussed that and we decided against it. We don't want to be too 
smart about this. Especially, note that the nat64 can be used in 
differetn enviroments, so either the v4 or the v6 side can be the 
external side, depending on the case.

> What is the definition of an ICMPv4 Query packet? RFC 792 does not
right, ICMPv4 does not define a subclass of ICMPv4 msgs that are not errors.
I have added the following definition in the terminology section

<t hangText="ICMP Query packet:">ICMP packets that are not ICMP error 
messages. For ICMPv6, ICMPv6
             Query Messages are the ICMPv6 Informational messages as 
defined in <xref target="RFC4443"></xref>.
             For ICMPv4, ICMPv4 Query messages are all ICMPv4 messages 
that are not ICMPv4 error messages.</t>

> reply/response ICMP messages.

I don't understand this comment, could you expand?
This section described how to handle ICMP packets that are not error 
mesages i.e. ICMP echo request/replies

Do you think something is missing?

> independent mapping here?
right, fixed

>        Without filtering - When "Endpoint-Independent Filtering" is used
fixed

> however can the NAT64 device be DoS from a session table point of view?
Right
added the following paragraph

Similarly, A DoS attack against the NAT64 can be crafted by sending either
     V4 or V6 SYN packets that consume memory in the form of session 
and/or binding table
     entries.

Regards, marcelo

> SE-164 80 Stockholm, Sweden| mailto:[email-masked]
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Mar 2010 07:17:39 -0700

Hi Marcelo,

Thanks for the response, I will remove the parts where what you propose
or have done is all ok or great.

I hope you have time to respond to this prior to the Behave session.
That way I can determine if we need to discuss one of the below issues
or not.

> can be external depending on the use case.

You apparently didn't get my proposal, but I am uncertain that it will
help. Local address are local in respect to the NAT64 and external from
it, thus there is one external v6 address and one external v4 address.

But lets leave this alone.

> actually assign addresses out of this prefix to links in the local IPv6

If you are using NSP that is NSP::/40 for stateful I expect that you can
insert into the routing tables a more specific routing prefix of the
translatable range like NSP:NSv4prefix::/64 if you assign /24 v4 address
to the translator for stateless usage. In practice you will need to do
even more specific prefixes to route the translatable addresses to
different parts of your v6 network.

And if people don't think the above is possible then it probably needs
to be pointed out in the address format document.

> to support simultaneous open of TCP connections.

Ok, so did understand this so you probably don't need to make
adjustments but I did go: Huuh. So a possibility here is to make clear
that you don't will have any BIB entry, only a session table entry.

> external side, depending on the case.

Ok, I was just checking. I think that is completely fine.

> Do you think something is missing?

Having re-read the section I don't think any change is needed.

I did notice one small editorial thing:

   An incoming ICMPv6 Informational packet with IPv6 source address X',
   IPv6 destination address Y' and ICMPv6 Identifier I1, is processed as
   follows:

      If the local security policy determines that ICMPv6 Informative
      packets are to be filtered, the packet is silently discarded.

Notice that the second paragraph uses "Informative" and the first
Informational. I think aligned terminology should be used here.

Thanks

Magnus Westerlund

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 25 Mar 2010 18:47:11 +0100

Hi Magnus,

replies to the open points below...

> different parts of your v6 network.
right, i see what you mean, i misunderstood you initial comment.

So, your initial comment was:

This is exactly right, the packets belonging to the stateless should not 
be delivered to the stateful function.

I am not sure where do we need to include that text, if anywhere. I am 
not convinced we need to write that down in this document. There has 
been many comments about writing a deployment/applicability document for 
nat64 and dns64, since there seem there are sevewral deployment 
guidelines that would be useful to give, maybe this would be a good 
place to do that, would that make sense to you? Or do you preffer i add 
something explicit in thsi document? or maybe in the framework document?

> that you don't will have any BIB entry, only a session table entry.
ok, rephrased as:

The result is that the NAT64 will not drop the packet based on the 
filtering, nor create a BIB entry.
Instead, the NAT64 will only create the session table entry and store 
the packet.
The motivation for this is to support simultaneous open of TCP connections.

fixed
Regards, marcelo

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Mar 2010 11:18:41 -0700

> something explicit in thsi document? or maybe in the framework document?

I think you are right that this is not the document to do it in. So lets
move forward with this document.

I think the WG should discuss what to do with the rest.

> The motivation for this is to support simultaneous open of TCP connections.

Okay, that makes it clear.

Cheers

Magnus Westerlund