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

From: Michael Tuexen <[email-masked]>
Date: Sun, 21 Oct 2012 20:50:35 +0200

Hi Steve,

I'm sorry for the late rely. See my comments in-line.

Best regards
Michael

On Mar 27, 2012, at 12:59 PM, Steve Padgett wrote:

> 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.
I added a sentence to avoid this. Thanks for bringing this up.
> 
> 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.
Well, the end-points have to deal with the case that these packets are
dropped anyway. So this would result in a suboptimal behavior.
> 
> 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).
Yes. We have not limitation.

Best regards
Michael
> Thanks!
> Steve