Re: FW: I-D Action:draft-muthu-behave-consent-freshness-00.txt
Muthu Arul Mozhi Perumal (mperumal <mperumal <at> cisco.com>
2012-03-06 19:23:44 GMT
|In other words, what's the difference between a consent request
|and a keepalive?
A keepalive is a Binding indication that does not evoke a response,
whereas a consent request does.
|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.
<snip from the RFC5245>
B.4. Importance of the STUN Username
ICE requires the usage of message integrity with STUN using its
short-term credential functionality. The actual short-term
credential is formed by exchanging username fragments in the SDP
offer/answer exchange.
B.10. Why Are Binding Indications Used for Keepalives?
Additionally, using a Binding Indication allows integrity to be
disabled, allowing for better performance. This is useful for large-
scale endpoints, such as PSTN gateways and SBCs.
</snip>
It doesn't look ICE intended to limit the message integrity and
short-term auth for connectivity checks alone -- it looks applicable for
any Binding request/response transaction.
<snip from the RFC5245>
10. Keepalives
Though Binding Indications are used for keepalives,
an agent MUST be prepared to receive a connectivity check as well.
If a connectivity check is received, a response is generated as
discussed in [RFC5389], but there is no impact on ICE processing
otherwise.
</snip>
If a connectivity check is received for keepalive, it should use the
message integrity and short-term auth, I think.
Muthu
|-----Original Message-----
|From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
Behalf Of Simon Perreault
|Sent: Wednesday, March 07, 2012 12:20 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: behave <at> ietf.org
|Subject: Re: [BEHAVE] FW: I-D
Action:draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-06 13:06, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |- Looking at section "6. STUN Consent Method Processing",
|> |I don't see any difference between a Binding request and
|> |a Consent request on the server side. So how could a Consent
|> |request have different semantics than a Binding request if
|> |they are processed identically by the server?
|>
|> To make sure I understand correctly, by a server you don't mean a
STUN
|> server sitting in the Internet used for resolving the NAT'ed address,
|> right? Such a server isn't expected to receive a consent request.
|> Consent request/response is expected to be used b/w two endpoints
|> involved in a real-time communication session.
|
|Right. By "server" I mean the peer that receives the STUN request.
|
|> From the server side, the main difference b/w the Binding request
|> processing and the Consent request processing is the message
integrity
|> verification. While a Binding request in the ICE usage would require
|> verification of the message integrity using the short-term credential
|> mechanism, the consent request will not. A consent request is also
not
|> expected to contain any other attribute except FINGERPRINT (and
probably
|> SOFTWARE). So, once the server identifies it as a consent request
based
|> on the message type fields in the STUN header, it would branch out of
|> Binding request processing and process the request as a consent
request.
|
|What does "process the request as a consent request" mean? From the
|draft it looks like it could mean exactly the same as for a Binding
|request...
|
|In other words, what's the difference between a consent request and a
|keepalive?
|
|> |- Why a new method instead of a new attribute?
|>
|> As described in the design considerations section, the ICE usage
|> requires the message integrity and short-term credentials to be used
|> with Binding request/response. These are not needed for consent
|> freshness. One could add a new attribute to call out an ICE
exception.
|
|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.
|
|> However, depending on where in the stack an implementation does the
|> integrity verification, an implementation may throw out a Binding
|> request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
|> attributes. In addition, a Binding request sent for consent freshness
|> can cause ICE reprocessing if an implementation doesn't handle it
|> properly.
|
|That argument can be used to justify anything. I could say that your
new
|Consent request could be interpreted as a Crash-Right-Now message if an
|implementation doesn't handle it properly.
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
|STUN/TURN server --> http://numb.viagenie.ca
|_______________________________________________
|Behave mailing list
|Behave <at> ietf.org
|https://www.ietf.org/mailman/listinfo/behave
RSS Feed