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

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Dec 2004 21:06:31 -0500

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

---

From: "Elisabetta Carrara \(KI/EAB\)" <[email-masked]>
Date: Thu, 9 Dec 2004 12:02:36 +0100

Hi Francois,
thanks for your comments. See in-line.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Francois Audet
>Sent: den 7 december 2004 03:07
>To: [email-masked]'
>Cc: [email-masked]'; Mats Näslund (KI/EAB); 
>Jari Arkko (JO/LMF); [email-masked]'
>Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt
>
>
>Hi, 
>I have a 2 comments on 
>- 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 ... 
>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. 

Ok. 
The draft has undergone the AD's review and has been 
recently resubmitted to IESG. Hence, since what you suggest 
is wording for better clarification, we will try to take 
the chance and add this during IESG review process. 

> 
>----------------------- 
>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.

yes, that seems the appropriate place.

Cheers
/E