[MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-37: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 8.1. Per “These require techniques for message integrity and
encryption for offers and answers, which are satisfied by the TLS mechanism
[RFC3261] when SIP is used”, the guidance is right (use TLS), but this
reference is outdated.  Section 26.2.1 of RFC3261 provides rather old guidance
on the ciphersuite.  Is there a reason why not to use BCP195 for guidance on
versions/ciphersuites?

(2) Section 8.2.1, The “voice hammer attack” appears to be an artifact of SDP. 
The text explicitly notes that this attack is not “specific to ICE but that ICE
can help provide a remediation” (aside, should “remediation” be “mitigation”). 
However, the preceding introductory section (8.2) explicitly says “there are
several attacks possible with ICE”.  These two statements aren’t consistent.

(3) Section 8.2.2.  This section reads like an operational consideration.  The
setup scoped in the parent Section 8.2, “there are several attacks possible
with ICE when the attacker is an authenticated and valid participant in the ICE
exchange”, isn’t discussed here (i.e., how is the presence or absence of an ALG
germane to an attacker who is a participant in the ICE exchange)

(4) Section 8.  Is there a reason why the security considerations from RFC8445
are not noted as also applying (e.g., Section 19.1 - .4.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(5) Section 3.2.6.  The example in this section is appreciated.  Additional
text to explain what this example is showing would be helpful.

(6) Section 3.4.1.2.1. Per “the offer MUST include the same set of ICE-related
information that the offerer included in the previous offer or answer”, what
happens if the ICE information is different?

(7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling, it MUST
include the ‘a=remote-candidates’ attribute for each data stream whose check
list is in the completed state”, what is a ‘check list’ in this context?

(8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they MUST
have identical ice-pwd's”, what happens if there are not identical?

(9) Section 4.4. Per “Its large upper limit allows for increased amounts of
randomness to be added over time”, what is the time horizon being mentioned? 
Is this saying that in the future, longer password and users could be adopted?

(10) Section 4.5.  Unlike the other sections in 4.*, this one doesn’t have an
example.

(11) Section 8.2.  The title “Insider Attack” seems like a forced fit – perhaps
“Malicious Peer” (although Section 19.5 of RFC8445 seems to use that language)

(12) Section 8.2.2.  Per “Unfortunately, many ALGs are known to work poorly in
these corner cases”, it is worth reiterating here what that corner case is –
I’m inferring it is what the ALF does when m= or c= has an internal address,
right?

(13) Appendix A.  (Just as Ben pointed out in his DISCUSS for the example in
Section 4.6) Shouldn’t the examples in this appendix include a
“a=ice-options:ice2” per the guidance in Section 3.2.1.5?