Consent-based Communications draft-ietf-sipping-consent-framework-01.txt draft-ietf-sipping-consent-reqs-00.txt

Requirements Clarify that REQ2 talks about amplification attacks Do we get rid of the second part of REQ9? –REQ 9: The solution shall work in an inter- domain context, without requiring pre- established relationships between domains.

Translation Identification CONSENT requests need to identify the exact translation they apply to at the relay –Request-URI –New header field

Using Request-URI

Using a Header Field

Comparison Request URI +No need to manipulate new headers -CONSENT does not carry the original Request-URI -Relay needs to make sure that the new Request-URI routes to it -Slightly more state info to be kept by relays (negligible) Header Field -Need to manipulate a new header +CONSENT carries explicitly the original Request-URI +Slightly less state info to be kept by relays (negligible)

Permission Upload SIP PUBLISH –SIP Identity can be used to authenticate the PUBLISH –Only permission upload (no read operation) XCAP –Return routability (using a token) –Permission upload and read –Requires XCAP support at clients Hybrid? –Both allowed

Third-Party Registrations The UA at the registered Contact does not support incoming TLS connections Man-in-the-middle attacks are possible –against the return routability test –but also against incoming traffic In scenarios where there is no security to begin with, the consent process can be circumvented