I've been selected as the secdir reviewer for this draft.  These
comments are intended for the security ADs (and other ADs); authors
please treat them as any other last call comments.

I have one major issue.
This draft is sufficiently unclear in its introductory material that I
found it very challenging to review.
What it's trying to do is to specify behavior for  handling of  ICE by
B2BUAs.
However, the introduction never says that; the introduction talks a lot
about the background for B2BUAS, ICE, STUN and related parts of the SIP
infrastructure.
Coming back to reading SIP documents after a number of years, the
bibliography provided in the introduction was useful, but the
introduction needs to describe what this document does.

The abstract sort of tries to describe what the document does.  However,
our process requires that the document and abstract stand independent of
each other.  The reader cannot be expected to read the abstract before
reading the document.
Also, the abstract claims that  this document specifies the handling of
STUN messages inside ICE.
Section 3 and 4 actually provide requirements for handilg of SDP
attributes, ICE processing and other things far beyond handling of STUN
messages.

My recommendation for addressing this issue is:

1) Update the abstract to make it clear that this is overall
requirements for B2BUAs interacting with ICE, not just requirements for
handling STUN messages.

2) Make sure everything the abstract says is near the front of the
introduction.  After introducing what STUN, ICE, and B2BUAs are, it's
important to explain the role of this document.

Once I understood what this document was trying to do I was able to
think about the security implications.
There really don't seem to be any new security implications with this
document.  The security considerations section is fairly lite, but the
introduction does point to the existing discussions of security of ICE
and B2BUAs and various latching techniques.
I don't think this protocol introduces or even really changes the
security landscape.
It gives guidance which if followed will mean that good actors don't
break the security mechansisms.  That is valuable because if the
frequency of good actors breaking security mechanisms is low enough, we
can actually rely on the security mechanisms.
So, I think the security considerations section is fine as-is, although
the security ADs may wish to ask for a couple of references to be copied
from the introduction.