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

Hello!

See inline...

> -----Original Message-----
> From: Fries Steffen [mailto:steffen.fries@siemens.com]
> Sent: den 14 april 2005 08:26
> To: Karl Norrman (KI/EAB)
> Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org
> Subject: 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. 

If exactly the same container is sent in the response (without changing it), 
then the function processing SDP as such would not even bother to 
send the vale to the MIKEY implementation as it is one of the parameters that hasn't 
been changed and shouldn't be processed (according to the offer/answer 
model).

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

Yes, it is more effective to not send the MIKEY data
in the response.  However, this *has* to be done to
comply to the offer/answer model, as we understand it.

Regards,
Karl

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