RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.

Hi Karl,

by thinking about your anwer, there are still open questions for me. 

> As we understand the offer/answer model (rfc3264), you should 
> keep the parameters that you do not wish to change constant 
> in the re-INVITE. So we also assume that if you try to comply 
> to the offer/answer model, you will include the MIKEY 
> parameter, but "ignore" it at the receiver during the SDP 
> processing as it has not been changed.

[stf] At the first glimpse this would mean that a sender of a MIKEY message
should store the MIKEY container in some place for later reuse, but this is
not really possible as parameter like timestamp and maybe RAND. Those may
need to change (otherwise, how could you detect replay?). From that point of
view the receiver of the MIKEY message needs to process the MIKEY container
in any case. 
Would'nt it be more efficient to not sent the MIKEY container if non of the
cryptographic context parameter has changed? This would save the processing
at sender and receiver and also bandwidth.

Regards
	Steffen

> 
> Regarding your question in your previous mail, the answer is no.
> 
> Regards,
> MIKEY-people
> 
> > ---------------------------- Original Message
> > ----------------------------
> > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.
> > From:    "Fries Steffen" <steffen.fries@siemens.com>
> > Date:    Mon, April 11, 2005 8:55 am
> > To:      elisabetta.carrara@ericsson.com
> > Cc:      mmusic@ietf.org
> > --------------------------------------------------------------
> > ------------
> > 
> > Hi Elisabetta,
> > 
> > recently a question came up in the usage of the key management 
> > extentions for SIP to use MIKEY:
> > 
> > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains 
> the following
> > statement:
> > 
> > "If the key management rejects the offer and the session 
> needs to be 
> > aborted, the answerer SHOULD return a "488 Not Acceptable Here" 
> > message, optionally also including one or more Warning 
> headers (a 306 
> > "Attribute not understood" when one of the parameters is not 
> > supported, and a 399 "Miscellaneous warning" with arbitrary 
> > information to be presented to a human user or logged, see Section 
> > 20.43 in [SIP]). Further details about the cause of failure MAY be 
> > described in an included message from the key management 
> protocol. The 
> > session is then aborted (and it is up to local policy or 
> end user to 
> > decide how to continue)."
> > 
> > Concerning the sentence in bold (The sentence before the 
> last sentence 
> > in quotes), how does it do that in the following scenario?:
> > A UA receives an INVITE request containing an SDP offer 
> with a MIKEY 
> > I_MESSAGE that is for some reason unacceptable. The 
> receiving UA will 
> > return a 488 response, which does not contain an SDP 
> answer. Therefore 
> > there is no way of embedding a MIKEY R_MESSAGE to indicate 
> the error. 
> > Is there any way to signla the MIKEY error in this case?
> > 
> > Regards
> > 	Steffen
> > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> > 
> > 
> > 
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic