Subject: [Tsvwg] Use of association IDs on UDP-style SCTP sockets (draft-ietf-tsvw g-sctpsocket-00.txt)

From: Mike Bartlett <[email-masked]>
Date: Fri, 15 Jun 2001 17:31:02 +0100

I have some comments on the use of association IDs on UDP-style SCTP sockets
as specified in the SCTP Sockets Mapping draft.  One of these is a real
problem (relating to the mechanism specified for refusing incoming
associations on UDP-style SCTP sockets).

These comments all relate to the fact that the SCTP_ASSOC_CHANGE
notification is the only way that the application gets to learn what the
association IDs are for the associations on its UDP-style sockets (they are
provided in the notification with sac_state=COMMUNICATION_UP).  This means
that an application which has disabled the SCTP_ASSOC_CHANGE notification,
using the SCTP_RECVASSOCEVNT socket option, can never identify an
association using an association ID.

(1) On a UDP-style socket the association ID is carried on all other
notifications (e.g. send failure), and also on SCTP_SNDRCV ancillary data,
as a means of correlating the event to an association.  The draft should
make it clear that the SCTP stack MUST also set a peer transport address in
the msg_name field returned on a recvmsg() call, so that applications which
do not receive SCTP_ASSOC_CHANGE notifications can still perform correlation
to an association.
 
For the ancillary data the msg_name should always contain the source
transport address for the data that it accompanies.  For notifications it
should contain the primary peer transport address.

(2) For certain socket options that relate to a single association (e.g.
SCTP_RTOINFO, SCTP_STATUS) the application must identify the association on
a UDP-style socket using the association ID.  Therefore it must enable
SCTP_ASSOC_CHANGE notifications.  The same applies if the application wishes
to branch off any associations on its UDP-style sockets by calling
sctp_peeloff() - it must know the association IDs, so it must  enable
SCTP_ASSOC_CHANGE notifications.  

Please make it clear in the draft that enabling SCTP_ASSOC_CHANGE
notifications is an essential pre-requisite for these operations.

(3) Sections 5.3.1.1 and 3.1.2 state that a client application which does
not want to accept incoming associations on a UDP-style socket must disable
the SCTP_ASSOC_CHANGE notification using the SCTP_RECVASSOCEVNT socket
option.  

There is a big problem with this.  As point (2) makes clear, there are
certain operations which an application can only perform an a UDP-style
socket if it has SCTP_ASSOC_CHANGE notifications turned on (and the
association ID is also useful, but not essential, for correlation purposes -
point (1)).

It seems clear to me that we need a new socket option to allow applications
to turn on/off acceptance of incoming associations on UDP sockets.  We
cannot use the suggested method of overloading the SCTP_RECVASSOCEVNT socket
option.

(4) If the change I suggest in point (3) is accepted then I also suggest
that the default setting for the SCTP_RECVASSOCEVNT socket option should be
*on* for UDP-style sockets (as it is for the SCTP_RECVDATAIOEVNT option -
section 7.3).  An application which does not receive SCTP_ASSOC_CHANGE
notifications on a UDP-style socket is at a considerable disadvantage, and
the change suggested in point (3) means that this is no longer a security
issue.

Best wishes

Mike Bartlett
Voice Networking Group
Data Connection Ltd
Tel: +44 20 8366 1177
Fax: +44 20 8363 1039
Email: [email-masked]
Web: http://www.dataconnection.com

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Sat, 23 Jun 2001 07:02:52 -0500

Jonathan Wood directed me to your messages.  Thanks very much for your
detailed analysis.  More comments follow, including ones directed at
Jonathan and Randy.

> do not receive SCTP_ASSOC_CHANGE notifications can still perform correlation

I have to agree.

> should contain the primary peer transport address.

These are the reasonable addresses to use.  If this were a standards
track draft rather than informational, I'd say the ancillary data
msg_name MUST contain the source transport address for the data it
accompanies, and the notifications SHOULD contain the primary peer
transport address.

> notifications is an essential pre-requisite for these operations.

This is a very good idea.  Jonathan, do you want me to compose text or
do you want to?

> cannot use the suggested method of overloading the SCTP_RECVASSOCEVNT socket

This makes sense to me.  Randy, what do you think?  I remember that we
had quite a lengthy discussion of controling incoming associations...

> the change suggested in point (3) means that this is no longer a security

This is my strong preference even in the absense of (3), though I
remember why we decided for the current default--some of the authors
were concerned about unwanted associations arriving during application
startup before the option could be turned off.  Suggestion (3)
addresses that concern.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 09:26:28 -0500

La Monte:

Thanks for digging this out.. I was going to go back
and find it in the archive and reply :)

some comments ...

> > do not receive SCTP_ASSOC_CHANGE notifications can still perform correlation

me too..

> accompanies, and the notifications SHOULD contain the primary peer

I agree :)

> This is a very good idea.  Jonathan, do you want me to compose text or

I think Jonathan already checked his earlier changes back into the cvs
tree ... so
why don't you make the changes...

> had quite a lengthy discussion of controling incoming associations...

If I remember right, we did the combined GET EVENTS/GET ASSOC's
automatically
has a convience. It seems right to me to have a:

SCTP_RECVASSOCEVNT
and a
SCTP_INBOUNDASSOC

option...

> startup before the option could be turned off.  Suggestion (3)

I concur 100%. Since we have the assoc_id a udp style socket really
NEEDS this information. I don't think asoc events should ever
be off for this style... Accepting of associatioins is a seperate
item. Having them as seperate options makes it easy.. You always
get assoc events by default... you do not get assoc's if you
do not enable them...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)