Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments

[Paul Kyzivat <[e-mail]>]

Roman,

On 1/24/17 2:18 PM, Roman Shpount wrote:

>         Replacing of TCP connection or DTLS association does not break
>         the SCTP
>         association. SCTP is designed to run over unreliable transports, so
>         short term loss of connectivity when one TCP connection or one DTLS
>         association is being replaced by the other would be handled by
>         the SCTP
>         re-transmit timers. Also, when ICE is used, switching from one ICE
>         candidate to another, including switching between two ICE tcp
>         candidates
>         or switching from udp to tcp candidate, does not affect existing
>         SCTP
>         association. Existing SCTP association continues to run despite the
>         underlying candidate switch and as far as SCTP association is
>         concerned
>         it is running over the same unreliable transport. Finally, DTLS
>         association can be re-established to force re-keying the long
>         running
>         connection. This can be done without affecting SCTP association
>         running
>         on top of these DTLS associations.
>
>         This is why we are saying that the SCTP association, the DTLS
>         association and the TCP connection are managed independently
>         from each
>         other.  Each can be established and  closed without impacting
>         others.
>         Each protocol uses its own means to detect connection closure,
>         failure
>         or timeout.
>
>
>     I can see that this can be a good thing when it is what you want/need.
>
>     OTOH, if one of the two parties involved changes, and there is no
>     state sharing, you need to establish a new SCTP association. This
>     may turn out to be the case even when the offerer doesn't know that
>     the other party has changed.
>
>     So how are these two cases distinguished in the signaling? AFAICT
>     the only thing available is sctp-port. If the offerer doesn't
>     realize a change is coming, then it won't change its port. And in
>     that case the answerer won't know what port its predecessor used, so
>     it might choose the same value.
>
>     Of course, this is largely a 3pcc scenario, and if it is initiated
>     in the middle then the middle can probably know to change the port
>     somewhere.
>
>     But I'm not sure if that is the only case.
>
>
> We have considered that issue and assumed that selecting a random
> sctp-port is sufficient to determine if this is the same vs new
> connection.

I see *no* mention that the sctp-port value should be chosen randomly. 
And IMO it is unnatural to suggest port values be random. There could be 
reasons for them not being random - for instance interop with SCTP over 
IP with well known ports. Also, while there is currently no spec for 
multiple SCTP associations in the same bundle, it is not hard to imagine 
that that might be a useful thing to do in the future. In that case 
random port numbers could be more troublesome.

> There is some possibility of collisions when answering party
> accidentally picks the same port as the one which was previously used
> for SCTP communications, but this is similar to ICE ufrag
> collisions, dtls-id collisions or to-tag collisions.

But those all use values that are specified to be random.

> I do agree that
> sctp-port has less random bits then ufrag, dtls-id, or to-tag, so it is
> more likely to collide. Please let us know if this is a sufficient point
> of concern to warrant adding more randomness by changing sctp-port
> definition (making it longer)

That isn't possible, because the port number and its format are 
specified in the SCTP spec.

> or adding another attribute. Another
> solution would be to require SCTP association restart on DTLS
> association restart and use random bits in dtls-id minimize the chance
> of collision.

The most straightforward way would be to follow the pattern used with 
comedia (rfv4145), with a=coonnection=new/existing. But that attribute 
couldn't be used, because it can already be in use for a TCP connection 
below it. Also, we have already abandoned using something akin to a=setup.

Unfortunately the end result we have arrived add is, IMO, a one-off hack 
that doesn't follow established approaches. This has arisen because we 
are negotiated layered protocols and the established SDP mechanisms 
don't have provision for that. But I don't think there is the will to 
clean this up.

> In general, I am not strongly attached to not restarting SCTP
> association on underlying transport change. I am even less attached to
> restarting SCTP on DTLS restart.

Coupling SCTP restart with one of those is a simple answer.

> What I do feel strongly about is:
>
> 1. Keeping SCTP association when ICE candidates change
> 2. Keeping SCTP association on ICE restart
>
> Keeping SCTP association on ICE restart has exactly the same properties
> as keeping SCTP association on transport change (it is unclear if ICE
> restart was caused by the same endpoint or by endpoint change due to
> 3pcc). Since ICE restart and transport change are essentially the same
> thing, I proposed that SCTP association is preserved in both cases. If
> we tie SCTP association restart to DTLS association restart we will get
> the desired result for ICE only at the cost of loosing re-key ability
> for the existing SCTP association.
>
> So, my questions are:
> 1. Is possibility of sctp-port collision large enough concern to change
> when SCTP association is restarted?
> 2. Would it be acceptable to lose ability to re-key DTLS association
> while running the same SCTP assignations and force SCTP association
> restart on DTLS association restart?

I'd like to hear what others have to say.

	Thanks,
	Paul