Subject: Comments on draft-ietf-tsvwg-natsupp-02.txt

From: Steve Padgett <[email-masked]>
Date: Tue, 27 Mar 2012 12:59:33 +0200

A couple comments on the SCTP NAT doc:

1) In section 8,  "Handling of Missing State", an ERROR packet is
being sent in response to a packet other than a "ABORT,
SHUTDOWN-COMPLETE or INIT-ACK" packet that doesn't exist in the
translation table on the inside.

It doesn't explicitly exclude ERROR messages here as well, but it
seems like it should (it may be implied, but I just don't see it
explicitly stated anywhere. I could be missing it).  Having this error
being generated because of another error seems like it has the
potential for creating an error storm/loop.

2) As a more generalized comment, it'd be nice to support a scenario
where the NAT box itself "supports" SCTP nat but only in a "passive"
mode where the nat box itself does not ever generate sctp packets. The
difference with the passive mode is that if there is an error or
collision in port #s/verification tags the just have the nat box drop
the packet, instead of responding with an error packet.  This would be
less graceful to the protocol itself (a significant negative), but, as
an advantage:
 - would make the nat-box implementation easier (arguably)
 - would be closer to the current NAT situation in
firewalls/routers/nat boxes today for TCP/UDP/ICMP
 - would likely generate less security risk (having the router respond
to every error'd packet may allow a dos attack against the router
itself if you flooded it with bad packets)

In a "tiny" nat box (aka a home CPE or phone tethering nat), not
sending the error codes may be ok because the risk of collisions is so
low (eg, possibly left up to the implementor).  In a "larger" nat box,
the customer may need these error packets.

It's also not clear if these error packets must be sent in response to
every packet or not (eg, if there can be rate-limiting, etc).

Thanks!
Steve