Subject: [BEHAVE] draft-ietf-behave-sctpnat-00.txt

From: <[email-masked]>
Date: Wed, 19 Nov 2008 20:01:07 +0100

Hi,

Please accept the following comments. Don't take them as being in
opposition to the
draft, I support this work, but I think that the proposed additions
(changes in fact) to the
SCTP protocol deserves a few more thoughts (text if you like).

A fundamental feature in SCTP, opposed to TCP, is the vtag. Multiplexing
with the vtag
makes SCTP less prone to injection attacks and it removes the need for
an TCP TIME-WAIT equivalent.
[Though, it introduces essentially a need for a vtag TIME-WAIT feature
although this is 
not carved in stone in the RFC (4960).] 

With the current standard then at any given time there will be 
at most one valid vtag tuple [local vtag, peer vtag] associated with a
flow in 
between two SCTP endpoints, i.e., using the terminology of
this draft:
at most one valid tuple
[External-vtag, Internal-vtag] 
for a flow identified otherwise by 
[External-Address, External-Port, Public-Address, Internal-Port].
And all packets with different vtags are to be dropped as stale (or
malicious) packets.

As I understand it, the NAT-supported features of this draft 
breaks with this paradigm as it allows for two associations to share the
same SCTP end-points, i.e., the
[External-Address, External-Port, Public-Address, Internal-Port]
as long as the vtags are different. 
This has at least the following implications:

SCTP implementations supporting this draft shall undergo a fundamental
change in that
end-point identifications now should be expanded to include a vtag
identifier. Depending on the
implementation this may or may not be a rather big change. That may just
be how it has to be, but I think that
it should be said more explicitly. 

A different issue is that the principle of categorizing packets as being
stale based on the freshness of the vtag seem 
to run into some problems. Standardly this is guaranteed by a TIME-WAIT
mechanism for vtag or something else which ensures that the same vtag it
not chosen "two times in a row" for different associations in between
the same endpoints. But as the end-point
is now effectively distributed over all the host sharing the same Public
address and Internal-port, it will no longer be so
easy to have this guarantee - unless this is something that one
envisaged to be implemented in the NAT, i.e.
discarding (ABORT) initiate v-tags which was used recently for the same
Public-address and Internal-port combination.
Yes it is highly unlikely to happen, still I think it deserves some
text.

Finally
(Sorry for sending this twice)
Is the following a nit or did I misunderstand a fundamental issue here ?

Shouldn't the following paragraph: (page 6)

"It should be noted that normally a NAT control block will be created.
However, it is possible that there is already a NAT control block with
the same External-Address, External-Port, External-VTag, Internal-VTag
but different Private-Address. In this case the INIT SHOULD be dropped
and an ABORT MAY be sent back. "

have read:

"It should be noted that normally a NAT control block will be created.
However, it is possible that there is already a NAT control block with
the same External-Address, External-Port, External-VTag, Internal-Port,
 
^^^^^^^^^^^^^^
Internal-VTag but different Private-Address. In this case the INIT
SHOULD be dropped and an ABORT MAY be sent back. "

- ??

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