Subject: [BEHAVE] Comments on draft-ietf-behave-sctpnat-01

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Aug 2009 01:27:19 +0000

I just read this document for the first time, and there are still
significant issues that need to be addressed.  My comments, both
technical and editorial, are at
http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-behave-sctpnat-01.pdf

A few of my comments duplicate things already discussed like the fact that
it contains normative changes to 4690.  I agree with the proposal to
remove them from this draft.

I won't detail here the other technical issues I found (you can find them
in the PDF) but a high level summary is that there is still a bunch of
logic missing, since the examples don't match the prescriptive behavior
that currently exists in section 5 (the behavior there mostly matches,
but the examples show a lot more things that aren't specified anywhere
in the doc).

-Dave

> -----Original Message-----
> From: Bruce Lowekamp [mailto:[email-masked]]
> Sent: Monday, July 27, 2009 12:38 AM
> To: [email-masked]; Behave Chairs; draft-ietf-behave-
> [email-masked]
> Subject: open issues in draft-ietf-behave-sctpnat-01
>
> 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 Tüxen <[email-masked]>
Date: Tue, 11 Aug 2009 09:44:25 +0200

Hi Dave,

thank you very much for the comments. We'll incorporate them during
the splitting of the document.

Best regards
Michael

On Aug 11, 2009, at 3:27 AM, Dave Thaler wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>