Subject: [MMUSIC] ice-tcp-11 and ICE-Lite

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Nov 2010 00:34:17 -0500

Howdy,
With regards to "lite" implementations in draft-mmusic-ice-lite-11, I copied the relevant sections at the bottom of this email, and the following are my comments/questions:

1) I am not clear on how this draft solves the IPv6 transition problem of dual-stack.  If one side is lite, then it reverts to rfc4145 procedures.  But rfc4145 has no means of indicating multiple address-family/ports, so how does a lite device offer both IPv4 and IPv6? 

2) Why would a device meeting the criteria for lite use "actpass" in its offer vs. "passive"?  To be lite it is knowingly on the public Internet, and since it doesn't know what the remote peer supports (could be ICE-TCP, could be just legacy) it can't rely on the behavior defined here for how the receiver of the offer will act.  No?

3) Although I applaud your reasonable choice of having a lite agent use rfc4145 procedures without additional complication, I am afraid the IESG or MMUSIC WG has not proven to be that reasonable in the past.  ICE-UDP required SHA-1 verification of each side's identity in order to work even with ICE-Lite.  In the TCP case, without a STUN SHA-1 verification inside the TCP connection, bad guys could steal the media TCP connection by connecting to the lite agent before the peer does.

-hadriel

------------------ relevant portions of ice-tcp-11 ---------------------

Section 3 says:
   Unlike for UDP, there are no lite implementation defined for TCP.
   Instead, an implementation that meets the criteria for a lite
   implementation as discussed in Appendix A of [RFC5245] can just use
   the mechanisms defined in [RFC4145], with constraints defined here on
   selection of attribute values (see Section 4).

Then section 4 says:
   If an offerer meets the criteria for lite as defined in Appendix A
   of [RFC5245], it omits any ICE attributes for its TCP-based media
   streams.  Instead, the offerer follows the procedures defined in
   [RFC4145] for constructing the offer.  However, the offerer MUST use
   a setup attribute of "actpass" for those streams.

Then section 6.1 says:
   Since this specification does not define a lite mode for ICE TCP, a
   lite implementation will include candidate attributes for its UDP
   streams, but no such attributes for its TCP streams.  An agent
   receiving such an offer MUST proceed with ICE in this case.  ICE will
   be used for the UDP streams, and [RFC4145] procedures will be used
   for the TCP streams.  However, if the offer indicates a setup
   direction of actpass, the answerer MUST utilize a=setup:active in the
   answer.  This is required to ensure proper directionality of
   connection establishment to work through NAT.

   Similarly, if an agent is lite, and receives an offer that includes
   streams with TCP candidates, it will omit candidates from the answer
   for those streams.  This will cause [RFC4145] procedures to be used
   for those streams.  In this case, the offer will indicate a direction
   of active, and the agent will use passive in its answer.

---

From: Ari Keranen <[email-masked]>
Date: Wed, 17 Nov 2010 15:12:47 +0100

Hi Hadriel,

Thanks again for your review; comments inline.

15.11.2010 6:34, Hadriel Kaplan wrote:
> Howdy, With regards to "lite" implementations in
> draft-mmusic-ice-lite-11, I copied the relevant sections at the
> bottom of this email, and the following are my comments/questions:
>
> 1) I am not clear on how this draft solves the IPv6 transition
> problem of dual-stack.  If one side is lite, then it reverts to
> rfc4145 procedures.  But rfc4145 has no means of indicating multiple
> address-family/ports, so how does a lite device offer both IPv4 and
> IPv6?

IIRC, the conclusion back then when this feature was introduced was that 
it simply doesn't and one should use full ICE instead to get proper IPv6 
transition feature.

> 2) Why would a device meeting the criteria for lite use "actpass" in
> its offer vs. "passive"?  To be lite it is knowingly on the public
> Internet, and since it doesn't know what the remote peer supports
> (could be ICE-TCP, could be just legacy) it can't rely on the
> behavior defined here for how the receiver of the offer will act.
> No?

The actpass behavior is defined in RFC4145 so if one is using TCP at 
all, they should understand actpass and thus know how to act. Regarding 
changing actpass to passive, I don't see a problem with it, but on the 
other hand not much benefits either; could be missing something though.

> 3) Although I applaud your reasonable choice of having a lite agent
> use rfc4145 procedures without additional complication, I am afraid
> the IESG or MMUSIC WG has not proven to be that reasonable in the
> past.  ICE-UDP required SHA-1 verification of each side's identity in
> order to work even with ICE-Lite.  In the TCP case, without a STUN
> SHA-1 verification inside the TCP connection, bad guys could steal
> the media TCP connection by connecting to the lite agent before the
> peer does.

I understood the WG consensus (at least so far) was to use RFC4145 for 
this. Also, we should not be worse off than with plain RFC4145, right?

Then again, if we do add the nomination connectivity check (I assume 
that's what you mean by the SHA-1 verification?) also to TCP lite I 
guess we could have both v4 and v6 candidates instead of plain RFC4145 
and thus also solve the dual-stack transition problem (will need to 
double check this when I have a bit more time for this). If this works, 
and doesn't end up complicating things much, I'd support this change.

Cheers,
Ari

> Section 3 says: Unlike for UDP, there are no lite implementation
> defined for TCP. Instead, an implementation that meets the criteria
> for a lite implementation as discussed in Appendix A of [RFC5245] can
> just use the mechanisms defined in [RFC4145], with constraints
> defined here on selection of attribute values (see Section 4).
>
> Then section 4 says: If an offerer meets the criteria for lite as
> defined in Appendix A of [RFC5245], it omits any ICE attributes for
> its TCP-based media streams.  Instead, the offerer follows the
> procedures defined in [RFC4145] for constructing the offer.  However,
> the offerer MUST use a setup attribute of "actpass" for those
> streams.
>
> Then section 6.1 says: Since this specification does not define a
> lite mode for ICE TCP, a lite implementation will include candidate
> attributes for its UDP streams, but no such attributes for its TCP
> streams.  An agent receiving such an offer MUST proceed with ICE in
> this case.  ICE will be used for the UDP streams, and [RFC4145]
> procedures will be used for the TCP streams.  However, if the offer
> indicates a setup direction of actpass, the answerer MUST utilize
> a=setup:active in the answer.  This is required to ensure proper
> directionality of connection establishment to work through NAT.
>
> for those streams.  In this case, the offer will indicate a
> direction of active, and the agent will use passive in its answer.
>