Re: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pekka,

thanks for the review

I think i have addressed most of the comments, but i have some follow ups.
See replies below.


El 03/06/10 11:06, Pekka Savola escribió:
On Tue, 1 Jun 2010, The IESG wrote:
- 'Stateful NAT64: Network Address and Protocol Translation from IPv6
  Clients to IPv4 Servers '
<draft-ietf-behave-v6v4-xlate-stateful-11.txt> as a Proposed Standard

I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 for ops-dir.

I believe the document is ready for publication, but there are a couple
of areas where minor clarifications could improve the document.

As a general comment, spec has good detail (esp S 3.5) on how to handle TCP, UDP and ICMP query traffic, but I did not find similar detail on how ICMP errors sent in response to such traffic would affect packet processing, state tables, etc.

The thing is that NAT64 only translated ICMP errors back and forth when it can but does not change its internal state in any way based on the errors.
In other words, ICMP errors received do not affect the NAT64 state.
I have made that explicit in the intor of the session handling section.
I have also reworded the other sections to explicitly address the ICMP error handling.


It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its
state table and said it's OK. There could be a number of unthought-of
cornercases.

From O&M perspective, the specification appears to be sufficiently operable
and configurable in IPv6->IPv4 translation. IPv4->IPv6 translation requires manually configured or unspecified bindings. Operationally this is not going to be sufficiently as the management interface is unspecified and e.g. MIB module or other configuration methods do not exist and are not in Behave WG charter. But this issue should not delay the publication of this document
and rather should be tackled later, if needed.

ok

The default TCP maximum session lifetime is 2 hours (from RFC5382). I
personally believe this is too small for long-lived sessions.

not sure if there is much we can do about this. We are relying on the consensus achieved in RFC5382, not sure how possible is to change that at this point.


some detailed comments:
-----------------------

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. [...]

.. which material is potentially covered by this? While the non-WG version was available prior to Nov 10, 2008, the authors should be able to say so.
It would be better if this disclaimer could be removed.  License info is
also an older version (from id-nits checker).

ok, i think we can do that

In S 3.4:

   If the incoming packet is an IPv6 packet that contains a protocol
   other than TCP, UDP or ICMPv6 in the last Next Header, then the
   packet SHOULD be discarded and, if the security policy permits, the
   NAT64 SHOULD send an ICMPv6 Destination Unreachable error message
   with Code 3 (Destination Unreachable) to the source address of the
   received packet.  NOTE: This behaviour may be updated by future
   documents that define how other protocols such as SCTP or DCCP are
   processed by NAT64.

.. I suppose this assumes the packet is unicast, as NAT64 is an unicast-only specification. Nonetheless I'd suggest that somewhere (probably earlier in
the spec) you'd explicitly say about one sentence on multicast; it's
currently not mentioned at all.  E.g. "A NAT64 device MUST ignore any
translation or actions when IPv4 or IPv6 destination address is a multicast
or the limited broadcast address (255.255.255.255)." (maybe with more
precise definition what to do instead.)

I have added a sentence that states that multicast is out of the scope of this specification. I would rather not to define what to do with multicast packets in this spec, so that if a multicast translator is defined, as proposed by stig, then we don't need to update this spec, makes sense?

The same applies but more strongly to the following IPv4 paragraph.  More
strongly because IPv4 spec does not allow generating ICMPv4's in response to
multicast packets while in ICMPv6 this is acceptable under certain
conditions.
right, i have added a sentence in the beginning of the document that states that multicast traffic is out of the scope of the spec, so i think this would address this as well


NB: I see that IPv6 destination address is covered under 2nd paragraph of S
3.5 but a more explicit mention might be worthwhile.

In S 3.5.1:

      *  The STE destination IPv4 transport is set to (Z(Y'),y), y being
         the same port as the STE destination IPv6 transport address and
         Z(Y') being algorithmically generated from the IPv6 destination
         address (i.e.  Y') using the reverse algorithm as specified in
         Section 3.5.4.

.. S 3.5.2 can hardly be said to specify any algorithm, but it certainly
doesn't even mention the reverse algorithm (however trivial it might be).


removed the expression "specified in"
In section 3.5.4 it mentions that the algorithm must be reversible and that it must be possible to generate the IP4 address out of its IPv6 representation


In S 3.5.2:

      V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by
      the NAT64, implying that a TCP connection is being initiated from
      the IPv4 side.  The NAT64 is now waiting for a matching IPv6
      packet containing the TCP SYN in the opposite direction.
...
   A TCP segment with the SYN flag set that is received through the IPv6
   interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6
   FIN + V4 FIN, V6 RST and V4 RST.

.. this is somewhat confusing because you appear to be using "V4 SYN RCV" to mean "only SYN flag set" (due to "being initiated from ...") while "V4 SYN" later means "SYN [and possibly ACK] flag set". The same applies to V6 of course.
Maybe reword?  Maybe "being initiated from.." and this distinction is not
even necessary, because you don't have it on V4 FIN RCV side either? (Though
when creating sessions, the semantics differ slightly depending on the
initiator.)
changed the state name to V4 INIT and V6 INIT

V4 FIN RCV, V6 FIN RCV and V4 FIN + V6 FIN are listed in the state diagram
without "RCV" keyword, and this should be corrected.

done

I'm also a bit hesitant to include 4 min T.O., 2hrs etc. in the diagram as
these seem to be certain _minimum_ values and the implementation would be
free to use some other values as well.  More general description would be
slightly better.
I have changes the numbers by the protocol constants TCP_TRANS and TCP_EST
I also change the 4MIN state name to TRANS


A cornercase from specification language point of view are those TCP flags that could at least in theory be applicable alongside "state flags": URG and
PSH.

I am not sure how these would affect the nat64 behaviour...

In S 3.5.2.2:

         +  The STE transport IPv6 source address is left unspecified
            and may be populated by other protocols out of the scope of
            this specification.


... what does leaving source address unspecified mean in the context of TCP
session table searches, packets on the wire etc.?

we had a long discussion about this in the WG. My position, is that in this case, i.e. when there is no BIB entry, the V4 SYN shoudl be simply dropped. Some people argued that it may be possible that there is another protocol that would be able to populate the BIB off band and that why this was left unspecified.
As i said, i don't have any problem with changing this
         The lifetime of the STE entry is set to TCP_INCOMING_SYN as per
         [RFC5382] and the packet is stored.  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.

... for how long is the packet supposed to be stored?

during the lifetime of the state
If the state times out, all the state info is discarded including the packet. should i clarify that on the draft?
  Will it ever be sent
out on the wire?
well, it may be sent inside an ICMP error message in case the state times out and the V& SYN has not arrived. At that point the NAT64 will send back to the V4 initiator an ICMP error containing the original V4 SYN, to notify that the TCP connection was not established

If yes, what will replace the "unspecified" IPv6 source
address then?
As i mentioned earlier, how the IPv6 source address is populated is out of the scope of the spec.

  If not, what's the point of storing a packet in the first
place (instead of just creating a state entry and dropping it)? An explicit reference how the packet processing continues could be useful here (it seems it does not continue).
In V4 SYN state processing description it reads:

   If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code
   3) containing the IPv4 SYN packet stored is sent back to the source
   of the v4 SYN, the session table entry is deleted and, the state is
   moved to CLOSED.


This is the only thing that happens with the stored packet.


The same also applies in the case a TCP BIB entry
exist (similar description).

I don't understand this one.

   *** ESTABLISHED ***

   If a V4 FIN packet is received, the packet is translated and
   forwarded.  The state is moved to V4 FIN RCV.

   If a V6 FIN packet is received, the packet is translated and
   forwarded.  The state is moved to V6 FIN RCV.

.. I suppose you're referring here to _only_ FIN flag set.
No (but maybe i am missing something)

Does a V4 FIN
packet with FIN+ACK flag set more the state to V4 FIN RCV?

yes, what would be the problem with that?

In S 3.5.3,

          If the packet is discarded, then an ICMP error message
      MAY be sent to the original sender of the packet, unless the
      discarded packet is itself an ICMP message.

.. there are copy/paste/logical errors here, and this also seems to apply to similar sections on UDP (at least). First of all, under UDP section, isn't
it already known which kind of packet is in question?
correct, i have removed that

Isn't the "itself an ICMP message" condition wrong and should be "itself an ICMP error
message"?
correct, but i have removed that sentence as per above

  Is it intentional that the "ICMP packet" condition is different
for BIB entry search and address-dependent filtering search?

You mean that in the address dependent searhc they also include the dest address Y? That is intentional.

S 3.5.3 deals with ICMP Query sessions, so from that perspective, this
should always result in an ICMP error message generation?

I am not sure what do you mean. Processing in section 3.5.3 results in translating the ICMP query into an ICMP query when it is possible. That shouldn't result in ICMP errors, unless it is not possible to make the transaltion.

In S 3.6.1:

   When translating in the IPv4 --> IPv6 direction, let the incoming
   source and destination transport addresses in the 5-tuple be (S,s)
   and (D,d) respectively.  The outgoing source transport address is
   computed as follows:

      The outgoing source transport address is generated from S using
      the address transformation algorithm described in Section 3.5.4.

      The BIB table is searched for an entry (X',x) <--> (D,d), and if
      one is found, the outgoing destination transport address is set to
      (X',x).

.. you don't mention what happens if an entry is not found in the BIB table. (maybe the assumption is that you should never arrive at this step if the BIB
entry does not exist..) -- the same also applies in 3.6.2.

the thing is that either a BIB entry is created during the processing of the session described in the earlier section, or the packet is discarded in the previou section, so if the processing makes it to this point, there must be a BIB entry (if not, the packet has already been discarded)

5.3.  Attacks on NAT64

.. it might be worth also mentioning the "packet is stored" case already
mentioned above in the context of simultaneous opens.


added the following sentence

 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. In the case of IPv4 SYNs the situation is aggravated by thee requirement to also store the data packets for a given amount of time, requiring more memory from the NAT64 device.
editorial:
----------

In S 3.2 also later:

(X',Y',I1) <--> (T,Z,I2)

.. because ICMP identifier corresponds to a port number in some sense, and
port numbers are designated with lower-case letters, I wonder if in this
case as well it would be better to use 'i1' and 'i2'.
done

*  The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the fragment that contains OFFSET
         equal to zero.

s/OFFSET/fragment offset/
done

   o  When the protocol following the IP header is ICMP (Sections 3.4
      and 4.4) and it is an ICMP error message, the source and
      destination transport addresses in the embedded packet are set to
      the destination and source transport addresses from the outgoing
      5-tuple (note the swap of source and destination).

.. you're referring to S 3.4 & S 4.4 of [I-D.ietf-behave-v6v4-xlate], not
this document, and this may be confusing.  But reference to S 3.4 and 4.4
appears to be redundant and could maybe be removed here altogether.


done
   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

.. now published as an RFC.
__
fixed
_____________________________________________
Behave mailing list
Behave@xxxxxxxx
https://www.ietf.org/mailman/listinfo/behave


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]