Subject: [tsvwg] draft-ietf-tsvwg-natsupp-06.txt

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Sun, 3 Nov 2013 15:53:12 +0100

HI,

I have finally managed to review the SCTP Nat traversal draft,
draft-ietf-tsvwg-natsupp-06.txt.

For what they are worth, please accept the following comments.

General:

Description of SCTP NAT traversal is spread over two drafts,
draft-ietf-tsvwg-natsupp-06.txt and draft-ietf-behave-sctpnat-09.txt.

I believe that some of the more detailed information contained in the
second draft, draft-ietf-behave-sctpnat-09.txt, needs to be replicated in

draft-ietf-tsvwg-natsupp-06.txt. Especially draft-ietf-behave-sctpnat-09.txt
is more precise when defining the messages exchange sequences

and the message content on the legs of SCTP host <- > NAT <-> Internet (<->
NAT) <-> SCTP host. This informaiton is lacking from
draft-ietf-tsvwg-natsupp-06.txt,

even if it is absolutely crucial in order to verify and fully understand
the SCTP endpoint protocol operations.

I may be mistaken, but to me it looks from the message sequence diagrams of
draft-ietf-behave-sctpnat-09.txt

as if the SCTP NAT traversal mechanism rely on that an ASCONF message is
accepted by peer,

even if neither the source address of the packet nor an address in the
address parameter of the ASCONF serve to identify the association.

I.e., neither is yet part of the association. This is in conflict with
Section 5.2 of RFC5061.

I understand that the new vtag parameter may give some extra information to
check with and

I suppose that one may possibly wave this check of RFC5061, but I believe
that it changes the security situation substantially.

Details:

Section 1, first paragraph: One might clarify that by pure NAT then not
only, only one SCTP capable host may reside behind a NAT, but

also only SH SCTP can be supported.

Section 1, table 1:

Unless I am mistaken (see below section 5.6 #2) then unless present
proposal is extended, then full felexible MH support is not achieved by the
proosed solution.

Meaning that by ASCONF only one mapping entry for the peer end-point, i.e.,
only one peer end-point address, is created in the the NAT which fronts

the secondary public address. Here I forsee that we may get into
discussions as to whether SCTP MH associations are intended to deploy only

one path or mulitple paths per peer address. Still the specification here
puts more limitations on the paths available for the association than

RFC4960, indeed some paths are explicitly excluded, and I believe that this
needs to be explicitly noted somewhere in the draft.

Section 5.3, 3rd paragraph, typo:

In a packet containing an INIT-ACK chunk à If a packet containing an
INIT-ACK chunk

Section 5.4: paragraph after first bullet list:

When associatons are distinguished by vtags only, the semantics of OoTB
packets are changed. Shall ABORTS be returned for packets that do not match
from a vtag perspective,

but otherwise matches an associaton ? In RFC4960 ABORTS are not returned
for such packets as the packets are considered stale.

Such ABORT are NICE only – so perhaps one will have them not be generated ?

Having said that then it is not clear to me how the NATs will handle ABORTs
from external side with reflected vtag.

Section 5.5: Third bullet:

It refers to that the procedures for generating an ASCONF chunk can be
found in RFC5061. I believe that information given in
draft-ietf-behave-sctpnat-09.txt on

the address to place in the ASCONF chunk and add IP and deleted IP handling
need be added here.

Section 5.5: Second paragraph after bullet list:

It says that the peer endpoint should follow the procedures of RFC5061 when
processing the ASCONF. But if the ASCONF have the format indicated in
draft-ietf-behave-sctpnat-09.txt,

then both the source address and the address in the ASCONF may be new to
peer.

Section 5.6:

#1:

The format of the ASCONF chunk to use when adding addresses should be
detailed.

#2:

It seems that by the ASCONF mechanism then one entry per additional public
address is added in the NAT which fronts the respective public address.

Towards a MH peer endpoint it seems that one then miss the “full mess”
mapping entries. The “full mess” entries, according to
draft-ietf-behave-sctpnat-09.txt,

are created for the publicc address used for INIT. This assymetri
represents a limitation compared to RFC4960.

A solution to the problem could be to have the ASCONF ACK be entended to
include information on full set of peer addresses.

The same limitation seem to be the case when a NAT looses its state, but in
this situation the limitation is perhaps more acceptable.

Section 8:

Comments here pend resolution (or understanding) of how to process ASCONF
chunks when all addresses are new to the receiver.

 BR, Karen