Subject: [BEHAVE] open issues in draft-ietf-behave-sctpnat-01

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 27 Jul 2009 09:38:04 +0200

There was a thread on the behave mailing list with the subject "SCTP
NAT questions and concerns" that started on 11/20/08 and ran through
11/22/08 with a few additional comments from Dan on 12/17.  My belief
is that there were a number of issues identified in that thread that
were not addressed by the -01 revision.  It's been awhile, but I'm
going to try to summarize some of the open issues:

- the draft does not use the same terminology as 4787 to describe NAT
behavior.  (Magnus also started a thread on 11/20 that discussed
terminology here in more detail.)  It also does not use the same
format to define a list of requirements, which may be desirable for
uniformity.

- the draft is BCP, but specifies normative changes to SCTP

- the specified changes to SCTP (NAT_SUPPORTED) essentially only
interoperate with other similarly enhanced SCTP implementations, so
non-NAT-aware implementations don't benefit from the SCTP NAT

-  In the world we are quickly hurtling toward,
there will be no way to tell if you are going through a NAT.  Between
NAT444, NAT46, and NAT64, you can have a public IP address
communicating with another public IP address that goes through a NAT.
If you want that to work with SCTP, I think the implication is that
this flag needs to always be set, which eliminates restart from the
SCTP feature set.

- the draft needs to clearly state that a rendezvous service is
necessary to exchange vtags to make a connection

- overloading the vtag to provide multiplexing support may reduce its
usefulness for security and freshness.  (I think this comment was more
that this should be explicitly acknowledged rather than it being a
problem to do so.)

- if a NAT needs to send an ABORT to force an SCTP app to pick a
different port, this has significant implications for application
design, since they may have already published their chosen port via
another mechanism

I think there were a few other issues raised in the thread, as well.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Jul 2009 10:18:57 +0200

Hi Bruce,

thanks for the e-mail.

Comments on-line.

Best regards
Michael

> format to define a list of requirements, which may be desirable for
The next version will use a terminology based on that discussion.
> - the draft is BCP, but specifies normative changes to SCTP
We need some error causes, maybe it should be PS.
> non-NAT-aware implementations don't benefit from the SCTP NAT
Well, then there are some limitations, like the handling of port
number collisions.
> necessary to exchange vtags to make a connection
For the P2P case you need a rendezvous service for the IP-addresses,
but you do not need a rendezvous service for vtags. You just set
up an association.
> that this should be explicitly acknowledged rather than it being a
It is still a random number. So why does it affect the protection
against blind attackers?
> design, since they may have already published their chosen port via
In this case it will fail the assocation. In case a different v-tag
might be used, this is not needed.
> I think there were a few other issues raised in the thread, as well.
I will try to address them with the next version.