Subject: [BEHAVE] draft-ietf-behave-sctpnat-04

From: Nikolay Melnikov <[email-masked]>
Date: Mon, 14 Mar 2011 13:22:15 +0100

Hello everyone,

I bumped into several statements and (what I consider to be) typos at
my initial read of the document, so I decided not to postpone and
report them.

5.  Limitations of classical NAPT for SCTP

    This would add considerable (?overhead?) to the NAT computational
burden, however hardware support may mitigate this in some
implementations.

6.  The SCTP specific variant of NAT

     It is also possible that a connection to External-Address and
External-Port exists without an<space missing>
Internal-VTag

7.  Nat to SCTP

   This document at various places discusses the sending of specialized
   SCTP chunks (e.g. an ABORT with <inconsistent throughout the
document, should be: M-Bit><M bit> set).

"

9. Simplification for small NATs

   Small NAT boxes, i.e.  NAT boxes which only have to support a small
   number of concurrent SCTP associations, MAY not take the external
   address into account when processing packets.  Therefore the
   External-Address could also be removed from the NAT table.

   This simplification may make implementing a NAT box easier, however,
   the collision probability is higher than using a mapping which takes
   the external address into account.
"

Is the risk of higher collision probability worth "implementation
simplification"? Does it make sense to have this section at all?

Shouldn't the multi-homed "server-side" of figures in 10.3 look as follows
(to comply with figure in 10.2):

                +-------+                        +--------+
              /-| NAT 1 |-\      /--\/--\      /-|Router 1|-\
 +------+    /  +-------+  \    /        \    /  +--------+  \ +--------+
 | Host |===                ===| Internet |==                ==| Host B |
 |   A  |    \  +-------+  /    \        /    \  +--------+  / +--------+
 +------+     \-| NAT 2 |-/      \--/\--/      \-|Router 2|-/
                +-------+                        +--------+

10.5

Host A send<s> INIT-ACK, which can pass through NAT B:

Question: From the example in 10.5, the INIT packet from host A creates an
entry in NAT A, but is discarded at NAT B. What follows, is an INIT packet
from host B, which creates an appropriate entry in NAT B. It is mentioned
that the rendezvous points are involved in this case, could you please
explain to me how? Does host B send an INIT packet  a hint from that
rendezvous point?

nik
-- 
Nikolay Melnikov
School of Engineering and Science
Jacobs University Bremen

<http://www.jacobs-university.de/>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 14 Mar 2011 20:09:36 +0100

Hi Nik,

thanks for comments.

Best regards
Michael
On Mar 14, 2011, at 1:22 PM, Nikolay Melnikov wrote:

> Hello everyone,
> 
> I bumped into several statements and (what I consider to be) typos at my initial read of the document, so I decided not to postpone and report them. 
> 
> 
> 
> 
> 
> 
>     This would add considerable (?overhead?) to the NAT computational burden, however hardware support may mitigate this in some implementations.
It adds to the computational burden... We wanted to say that additional work is needed.
>      It is also possible that a connection to External-Address and External-Port exists without an<space missing>
> Internal-VTag
Fixed.
>    SCTP chunks (e.g. an ABORT with <inconsistent throughout the document, should be: M-Bit><M bit> set).
Fixed.
> Is the risk of higher collision probability worth "implementation simplification"? Does it make sense to have this section at all? 
This section has to change anyway...
> 
> 
> 
> Shouldn't the multi-homed "server-side" of figures in 10.3 look as follows (to comply with figure in 10.2):
> 
> 
>                 +-------+                        +--------+
I agree, that the figures in 10.2 and 10.3 should show Host B in a similar way.
I'll fix it for the next rev.
> Question: From the example in 10.5, the INIT packet from host A creates an entry in NAT A, but is discarded at NAT B. What follows, is an INIT packet from host B, which creates an appropriate entry in NAT B. It is mentioned that the rendezvous points are involved in this case, could you please explain to me how? Does host B send an INIT packet  a hint from that rendezvous point?
Host A must know external address and port number of Host B and vice versa.
To get this information, both node connect to a rendezvous server and exchange
this information.
This is described in more detail in
Network Address Translation for the Stream Control Transmission Protocol
Tüxen, M.; Rüngeler, I.; Rathgeb, E.
IEEE Network, 22(5):26-32, 2008.

Best regards
Michael