Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 15 Jan 2005 10:41:03 +0200

Hi,

Francois is right in pointing out that there is a known problem with SIP 
forking referred to as HERFP (Heterogeneous Error Response Forking 
Problem). RFC 3326 refers to it in its abstract.

We never got around to resolving this issue. However, as Francois 
suggests, there could be ways around it. If both UAs support 100rel the 
offer can be accepted in a provisional (e.g., 183) response. Further 
negotiations could be carried out using PRACKs, and when the key 
management procedure completed, the UAS could finally accept the session 
with a 200 OK response for the INVITE.

UAs that do not suppor 100rel would need to use a 200 OK or live with 
the HERFP, as Francois pointed out.

Regards,

Gonzalo

Francois Audet wrote:

> Hi,
> 
> I have a 2 comments on
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-12.txt.
> 
> 
> This first comment is for a clarification:
> 
> - Section 3.1.2 explains that SIP 488 is used for rejecting a key 
> management offer.
>   488 allows for the inclusion of an SDP indicating the capabilities of the
>   answerer (the same way an SDP in a 200 OK sent in an OPTIONS request 
> indicates
>   capabilities). It would be desireable to explain how this works with
>   kmgmt. I assume that this is what is meant by wording saying "Further 
> details
>   about the cause of failure MAY be described in an included message 
> from the key
>   management protocol." Perhaps a wording like the following would help:
> 
>         Further details about the media capabilities of the offerer MAY 
> be in
>         included in 488 according to normal RFC 3261 rules. Further 
> details about
>         the cause of the rejection of the key message itself MAY be 
> described in
>       the key message in the SDP in the 488, according to the rules
>         of the key management protocol. The session is then ...
> 
>  ...or something along those lines.
> 
>  It would also be worthwile to describe how this relates to MIKEY in
>  particular (i.e, that the MIKEY message itself in the key-mgmt may have
>  the key management rejection reason). It would also be helpful to have
>  an Example of a failure case for SIP 488/MIKEY.
>  
> -----------------------
> 
> This next comment is concerning a potential issue with SIP forking. I'm
> not sure we can fix it in MMUSIC, but I'll state it anyways.
> 
> - There is a somewhat unpleasant side-effect of using a SIP failure 
> response
>   for rejecting a key management message.
> 
> - Suppose that there is a SIP forking proxy forking the offer (in the 
> INVITE).
>   Let's say the call is forked to A and B. A is a device for which no
>   user is present at the time (say, an office phone). Suppose A rejects the
>   call with 401 Unauthorized because it needs authorization. Suppose the 
> user
>   is at home (B), but rejects the offer with 488 (because it's using the 
> key
>   management protocol used for the corporation which is different than 
> the one
>   used at home). The forking proxy will see both the 401 an the 488, but 
> can only
>   forward one to the offerer. There is nothing saying which one should 
> be forwarded
>   beyong the error response that indicates that there could be 
> retransmission (which
>   applies to both codes in this case). Worst, in this particular 
> example, if the proxy
>   follows the rule section 6/RFC 3261, chances are it will pick 401. 
> This means
>   that you won't be able to call home because you'll never receive a 488.
> 
> - This is a weakness of the forking procedures in SIP, and perhaps it 
> should be
>   addresses in the SIP working group.
> 
> - The other alternative would be to not consider the rejection of the 
> key as a
>   rejection of the offer. Instead of sending a 488, you would accept the
>   offer with an answer, and the key rejection would be included in the 
> key message
>   itself (which could then trigger another offer/answer). In other 
> words, the
>   offer/answer is sucessful, but the key exchanged is not. This would 
> have the obvious
>   advantage of the previous scenario working properly. However, if there 
> is no
>   suitable key management protocol, we could run into the reverse 
> problem (when the
>   user is at work (A) instead of (B). In this case, the proxy would 
> forward the
>   200 with the answer with the key message, and drop the 401. There 
> would be another
>   offer/answer round which would then fail. The caller in this case 
> would never get
>   the 401.
> 
> I'm not sure how to deal with this forking issue.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic