Subject: [MMUSIC] Thinking about best-effort encryption

From: EKR <[email-masked]>
Date: Thu, 02 Nov 2006 11:48:30 -0800

As people will recall, in the RTPSEC meeting in Montreal it became clear
that we needed some way to support best-effort encryption. Loosely
speaking, it seems to me that there are two major ways to do this:

- Have nothing in the signalling and probe in the media plane
  as ZRTP does in bump in the wire mode.
- Have something in the offer that says "I will speak SRTP"
  but doesn't require it.

There have been a bunch of different suggestions about how to do this
(draft-andreasen-mmusic-sdp-capability-negotiation-01,
draft-kaplan-mmusic-best-effort-srtp-01, draft-zimmermann-avt-zrtp-02,
etc...). Regardless of which key management protocol we ultimately
choose, we need to sort the fundamental architectural issue of:

   Does the signalling (SDP) have to reflect RTP/SAVP?

If the answer to this question is "Yes", then we either need to:

1. Have some convenient way to offer multiple profiles (Flemming's
   draft surveys the space of options here).
2. Do an UPDATE with RTP/SAVP for every secure connection. I get
   the impression people find this distasteful.

If the answer is "No", then you can simplify the offer/answer exchange
by having the signal that you will do security in an a-line, but at the
cost of having the profile no longer reflect what's on the wire.

In either case, it seems like deciding this architectural issue is
something we need to do before we spend a lot of time discussing
the details of mechanisms.

-Ekr

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Nov 2006 12:27:27 -0800

>    Does the signalling (SDP) have to reflect RTP/SAVP?

I don't see any reason to require this.  That is, if someone invents  
a way to do it without specifying RTP/SAVP as the media transport or  
signaling it in some other way, then why would we prohibit this?

A more fundamental question might be "Can the signaling be used to  
convey any information for SRTP key establishment?" without  
specifying just what that would be.

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Nov 2006 17:17:17 -0500

While doing an update or reinvite may seem inelegant, I think it makes 
reasonable sense for the best effort mode. It certainly solves some 
problems regarding early media.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Nov 2006 14:17:50 -0800

> Regardless of which key management protocol we ultimately

This isn't just a question applicable to security -- this question is
also applicable to all other RTP profiles with offer/answer, such as
sending an offer where you want the RTP feedback profile (RTP/AVPF) if
the answerer supports it, otherwise you will accept RTP without
feedback (RTP/AVP).

Applicable to security, I expect RTP/AVPFCC
(draft-ietf-avt-tfrc-profile-06.txt) will also need an RTP/SAVPFCC
profile (it handwaves at such a thing in its section 3.  Eventually
there will be a profile for running RTP directly over DCCP, too
(without UDP, as is done by draft-ietf-avt-tfrc-profile-06).

We desperately need one solution for RTP profiles to be 
negotiated in SDP.

-d

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Nov 2006 22:36:52 +0000

> (without UDP, as is done by draft-ietf-avt-tfrc-profile-06).

That'd be draft-ietf-dccp-rtp-01.txt

Colin

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Nov 2006 16:41:51 -0600

You'll get very significant pushback from nework operators because of
increase
demand on proxies.

It also means that it's unsecure at answer time.

It's a valid mechanism, but I don't think it's  the best we can do.

I think IKR is right: we need to answer the very basic question about
do we "HAVE to use SAVP" to mean best effort.

The draft that Hadriel and I did assume "No". 
Flemming's draft assume "Yes". 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, November 02, 2006 2:17 PM
> To: EKR
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Thinking about best-effort encryption
> 
> While doing an update or reinvite may seem inelegant, I think 
> it makes reasonable sense for the best effort mode. It 
> certainly solves some problems regarding early media.
> 
> 	Paul
> 
> EKR wrote:
> > As people will recall, in the RTPSEC meeting in Montreal it became 
> > clear that we needed some way to support best-effort encryption. 
> > Loosely speaking, it seems to me that there are two major 
> ways to do this:
> > 
> > by having the signal that you will do security in an a-line, but at 
> > the cost of having the profile no longer reflect what's on the wire.
> > 
> > something we need to do before we spend a lot of time 
> discussing the 
> > details of mechanisms.
> > 
> > -Ekr
> >

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Nov 2006 11:00:32 -0800

> You'll get very significant pushback from nework operators because 
> of increase demand on proxies.
>

Er, I don't think so.  If you offer RTP/SAVP, and it's rejected by the
answerer (called party), the called party's phone won't ring at all.

> It's a valid mechanism, but I don't think it's  the best we can do.

Due to HERFP, I consider re-inviting a mechanism that cannot work.  Unless
we fix HERFP or deprecate forking.  

> I think IKR is right:  we need to answer the very basic question 
> about do we "HAVE to use SAVP" to mean best effort.
> 

A correction: both drafts put RTP/AVP in the "m=" line.

The offer in draft-andreasen-mmusic-sdp-capability-negotiation-01.txt, on
page 16, is here (I show the interesting lines with "**"):

           v=0 
           o=- 25678 753849 IN IP4 128.96.41.1 
           s=  
           c=IN IP4 128.96.41.1 
           t=0 0 
     **    m=audio 3456 RTP/AVP 0 18  
           a=sqn: 0 
     **    a=cdsc: 1 audio RTP/AVP 0 18  
     **    a=cdsc: 3 audio RTP/SAVP 0 18  
           a=capar: 1 a=crypto:1 AES_CM_128_HMAC_SHA1_32    
              inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
           a=pcfg: c=3,4 a=1 
           a=pcfg: c=1,2  

The answer is described and shown on page 17:

        Bob receives the SDP offer from Alice. Bob supports RTP, but not 
        SRTP, and hence he accepts the potential configuration for RTP 
        provided by Alice: 

           v=0 
           o=- 24351 621814 IN IP4 128.96.41.2 
           s=  
           c=IN IP4 128.96.41.2 
           t=0 0 
     **    m=audio 4567 RTP/AVP 0 18  
           a=acfg: c=1,2 

-d

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 03 Nov 2006 11:10:52 -0800

>      **    m=audio 4567 RTP/AVP 0 18  

Isn't that because it's not doing crypto in this example:

I read this text form S 4.4.2. as implying that if the answerer
had been willing to do SRTP you would need RTP/SAVP in the m-line.

        If the answerer chooses to accept one of the alternative potential 
        configurations instead of the actual configuration, the answerer MUST 
        generate an answer as if the offer contained that potential 
        configuration instead of the actual configuration included. The 
        answerer MUST also include an actual configuration attribute in the 
        answer that identifies the potential configuration from the offer 
        used by the answerer. The actual configuration attribute in the 
        answer MUST include information about the capabilities. Furthermore, 
        if the offered potential configuration included attribute capability 
        parameters and/or transport protocol capabilities, those parameters 
        MUST be included in the actual configuration attribute in the answer 
        as well.  

But maybe I've just misunderstood Flemming's draft.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Nov 2006 11:21:51 -0800

> > The offer in 
> > draft-andreasen-mmusic-sdp-capability-negotiation-01.txt, on

The offer, above, is for best-effort SRTP.  

The answerer can't do SRTP.

> had been willing to do SRTP you would need RTP/SAVP in the m-line.

I understood Francois was pointing out the difference in the m-lines of the
offer, not the answer.

I don't care much, myself, if the answer's m-line shows the RTP profile the
answerer selected.  It probably does ease some things, and Francois,
Hadriel, and I exchanged email a month ago that the offerer's RTP profile in
his m-line doesn't need to match the answerer's RTP profile in his m-line:
there is no RFC that requires those match.

> But maybe I've just misunderstood Flemming's draft.

I certainly miunderstood Francois' post, so my response to him may have been
confusing.

-d

---

From: Randell Jesup <[email-masked]>
Date: Sat, 04 Nov 2006 09:31:26 -0500

>answerer (called party), the called party's phone won't ring at all.

Even worse, if they have two phones (fork), the one that supports SAVP
will ring, and the other one won't, even if the caller would have been
willing to have an unencrypted conversation with that phone.

>we fix HERFP or deprecate forking.  

Reinvite is a real problem, agreed.

I'm a strong proponent of best-effort, since when making a call you don't
usually know if the final destination will support SAVP (and you really
can't know reliably).  It also will actually be deployable since it will
work with all the existing devices (without SRTP of course), like PSTN
gateways, without requiring (problematic) re-INVITE.

It's also pretty easy to implement.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 05 Nov 2006 22:07:51 -0500

>You'll get very significant pushback from nework operators because of
Right. Also, it smells like preconditions and we all know how popular 
they are.

>Flemming's draft assume "Yes". 
Not quite - only the answer contains the negotiated profile.

-- Flemming

>>FFrom [email-masked] Mon Nov 06 01:46:03 2006
Date: Sun, 05 Nov 2006 22:07:51 -0500
From: Flemming Andreasen <[email-masked]>
To: Francois Audet <[email-masked]>
Subject: Re: [MMUSIC] Thinking about best-effort encryption
Cc: [email-masked], Paul Kyzivat <[email-masked]>,
	[email-masked]

>You'll get very significant pushback from nework operators because of
Right. Also, it smells like preconditions and we all know how popular 
they are.

>Flemming's draft assume "Yes". 
Not quite - only the answer contains the negotiated profile.

-- Flemming

>>>There have been a bunch of different suggestions about how 
>>>      
>>>
>>to do this 
>>    
>>
>>>draft-kaplan-mmusic-best-effort-srtp-01, 
>>>      
>>>
>>draft-zimmermann-avt-zrtp-02, 
>>    
>>
>>>If the answer is "No", then you can simplify the 
>>>      
>>>
>>offer/answer exchange 
>>    
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 05 Nov 2006 22:01:03 -0500

There's a more fundamental architectural issue we need to agree on 
first, namely the scope of the problem we want to solve. It's difficult 
to design and compare solutions without agreement on this important 
point, and clearly different drafts have different scope presently. 
Having said that, rather than answering the specific question of whether 
you need to specifically indicate the negotiated profile on the "m=" 
line or not (which I agree is important, but probably more in the design 
phase), I'd like to take a step back and offer a couple of general 
design guidelines here that I believe are important to any solution to 
whatever agreed upon problem space we end up with:

1) Be explicit. Whatever we do needs to be signaled explicitly and 
should not rely on either one or both sides inferring the intentions of 
the other side based on some conventions for how particular existing SDP 
parameters and attributes happen to be included, omitted or combined in 
SDP. Syntax and parsing is easy; semantics is where the real work is, so 
let's not try and cut any syntatical corners here. I've seen it done in 
the past (more than once), and the result is always the same: unclear 
semantics in an ever growing list of cases, and future upgrades and 
changes become a nightmare.

2) Don't abandon current practice unless we have to. SDP and the 
offer/answer model is based on one side (offerer) indicating what it can 
and would like to do, and the other side (answerer) choosing from that 
and indicating the selected subset (possibly plus some additional 
parameters). There are explicit parameters defined for a lot of 
information already, and while it's certainly possible to change all of 
that, we sholdn't unless we have to. Case in point: If there is a way to 
communicate the profile, payload types, transport protocol, etc. being 
used, then let's reuse that. Again, I'm not as concerned about syntax as 
I am about semantics, which not only has to be specified for such new 
parameters, but now also needs to consider how they relate and interact 
with already defined semantics for the existing parameith Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 5 Nov 2006 22:44:29 -0800
Date: Sun, 05 Nov 2006 22:01:03 -0500
From: Flemming Andreasen <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [MMUSIC] Thinking about best-effort encryption
Cc: [email-masked], [email-masked]

There's a more fundamental architectural issue we need to agree on 
first, namely the scope of the problem we want to solve. It's difficult 
to design and compare solutions without agreement on this important 
point, and clearly different drafts have different scope presently. 
Having said that, rather than answering the specific question of whether 
you need to specifically indicate the negotiated profile on the "m=" 
line or not (which I agree is important, but probably more in the design 
phase), I'd like to take a step back and offer a couple of general 
design guidelines here that I believe are important to any solution to 
whatever agreed upon problem space we end up with:

1) Be explicit. Whatever we do needs to be signaled explicitly and 
should not rely on either one or both sides inferring the intentions of 
the other side based on some conventions for how particular existing SDP 
parameters and attributes happen to be included, omitted or combined in 
SDP. Syntax and parsing is easy; semantics is where the real work is, so 
let's not try and cut any syntatical corners here. I've seen it done in 
the past (more than once), and the result is always the same: unclear 
semantics in an ever growing list of cases, and future upgrades and 
changes become a nightmare.

2) Don't abandon current practice unless we have to. SDP and the 
offer/answer model is based on one side (offerer) indicating what it can 
and would like to do, and the other side (answerer) choosing from that 
and indicating the selected subset (possibly plus some additional 
parameters). There are explicit parameters defined for a lot of 
information already, and while it's certainly possible to change all of 
that, we sholdn't unless we have to. Case in point: If there is a way to 
communicate the profile, payload types, transport protocol, etc. being 
used, then let's reuse that. Again, I'm not as concerned about syntax as 
I am about semantics, which not only has to be specified for such new 
parameters, but now also needs to consider how they relate and interact 
with already defined semantics for the existing parameters.

3) Middle boxes exist and they need be able to infer things from the 
SDP. Whether we like it or not, middle boxes exist and we need to 
account for them. Cable, wireless, and wireline all have some type of 
SIP "proxy" (or rather B2BUA) that needs to inspect SIP signaling and 
either authorize and/or actually reserve QoS based on what it sees 
negotiated. Yes, I know this is outside the traditional IETF model, but 
we are looking for a solution to real-life problems here and hence we 
can't ignore this (or alternatively, we may have two different sets of 
problems to look at). The implication of this one is that the signaling 
channel (SDP) must provide some indication of what is actually going on 
(whether in an m= line or something else).

-- Flemming

ters.

3) Middle boxes exist and they need be able to infer things from the 
SDP. Whether we like it or not, middle boxes exist and we need to 
account for them. Cable, wireless, and wireline all have some type of 
SIP "proxy" (or rather B2BUA) that needs to inspect SIP signaling and 
either authorize and/or actually reserve QoS based on what it sees 
negotiated. Yes, I know this is outside the traditional IETF model, but 
we are looking for a solution to real-life problems here and hence we 
can't ignore this (or alternatively, we may have two different sets of 
problems to look at). The implication of this one is that the signaling 
channel (SDP) must provide some indication of what is actually going on 
(whether in an m= line or something else).

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 05 Nov 2006 22:11:09 -0500

>had been willing to do SRTP you would need RTP/SAVP in the m-line.
That is correct, however it would only be so in the answer. The offer 
would still look the same (and hence use "RTP/AVP" in the m= line).

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 05 Nov 2006 22:22:04 -0500

>there is no RFC that requires those match.
That would appear to be true (much to my surprise when I first saw this 
in the Kaplan draft), however there is also no RFC that specifies what 
to do if they don't match, and you can hardly argue this is in-line with 
the general offer/answer philosophy. Still, I don't think we are at a 
point where this particular question should drive the debate - we still 
need to agree on problem scope and a few fundamental design guidelines 
(per my note to EKR).

-- Flemming

---

From: Michael Richardson <[email-masked]>
Date: Sun, 05 Nov 2006 13:28:16 -0500

>>>>> "EKR" == EKR  <[email-masked]> writes:
    EKR> As people will recall, in the RTPSEC meeting in Montreal it
    EKR> became clear that we needed some way to support best-effort
    EKR> encryption. Loosely speaking, it seems to me that there are two
    EKR> major ways to do this: 

  That's fine, and I am all for this.
  I think, though, that the best effort encryption needs to be a subset
of the "encryption required" situation.

    EKR> - Have nothing in the signalling and probe in the media plane
    EKR> as ZRTP does in bump in the wire mode.

  That's fine, but then we can't ever make any decisions about the call
based upon whether or not it's secure.

    EKR> - Have something in the offer that says "I will speak SRTP"
    EKR> but doesn't require it.

  I think you mean "I am willing to speak SRTP".

    EKR> In either case, it seems like deciding this architectural issue is
    EKR> something we need to do before we spend a lot of time discussing
    EKR> the details of mechanisms.

  I agree.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Nov 2006 12:34:45 -0600

> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Sunday, November 05, 2006 19:22
> To: Dan Wing
> Cc: 'EKR'; Audet, Francois (SC100:3055); 'Paul Kyzivat'; 
> [email-masked]; [email-masked]
> That would appear to be true (much to my surprise when I 
> first saw this in the Kaplan draft), however there is also no 
> RFC that specifies what to do if they don't match, and you 
> can hardly argue this is in-line with the general 
> offer/answer philosophy. Still, I don't think we are at a 
> point where this particular question should drive the debate 
> - we still need to agree on problem scope and a few 
> fundamental design guidelines (per my note to EKR).

Agreed. This is a minor side issue.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Nov 2006 12:37:08 -0600

I'm not sure what you mean by "a subset of encryption required", but it's not
a sufficient condition.

It absolutely needs to be backward compatible with edpoints that
only support RTP (and no SRTP). Plain Jane endpoints that don't do SAVP, 
grouping, or any of the new esoteric stuff we are strugling with. By backward
compatible, I mean a normal non-SRTP session should be the result.

Both Flemming proposal and Hardriel/François's proposal are backward compatible.

The port overloading stuff is not, and neighter are some of the media grouping
ideas.

If it's not backward compatible it is a non-starter because nobody will be 
stupid enough to deploy a feature that means the phone suddently fails to 
make calls. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael 
> Richardson
> Sent: Sunday, November 05, 2006 10:28
> To: [email-masked]; [email-masked]
> Cc: EKR
> Subject: Re: Thinking about best-effort encryption
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>   I think, though, that the best effort encryption needs to 
> be a subset of the "encryption required" situation.
> 
>   That's fine, but then we can't ever make any decisions 
> about the call based upon whether or not it's secure.
> 
> ] [email-masked]      
> http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBRU4tP4CLcPvd0N1lAQJUBAf/ahvjezLqa1hadOcAJITev1VOmcGSRTKk
> e33xzYO8Lg6YUZxo6XLj1FaAAt15nlpfew5D8XZeLLXcNPQ/6KsEKdBxiCO748tj
> 6uCGHZRHPYGtg4GoA+c5XCHXnTCnCPHp4djtX9r3eK5FqLflY4vzPhIHtZyUeXIz
> nnY/3KcVzL7POvWWsYbmIJnReIWuzYDoouyoTPA3MxQXI3zIKtjlW+jxqVwuBHkV
> 81oxRR2b8Wr58whDMQgN6ynKoAZgOlFiMmaNGh9WeXrUMw1jo60doZvZX3CJunDF
> O5mM+BPQosocDb/xfBmu5zumtwW6hSfxjReyFa0Ikwxr7CneYh87GA==
> =miml
> -----END PGP SIGNATURE-----
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2006 11:03:46 -0800

>>>>> "Francois" == Francois Audet <[email-masked]> writes:
    Francois> I'm not sure what you mean by "a subset of encryption
    Francois> required", but it's not a sufficient condition.

  yes, I agree.

  It has to be ignored by systems that don't understand it, and it has
to be something that systems that *do* understand can require if they
want to.

    Francois> Both Flemming proposal and Hardriel/François's proposal
    Francois> are backward compatible.

...

    Francois> If it's not backward compatible it is a non-starter
    Francois> because nobody will be stupid enough to deploy a feature
    Francois> that means the phone suddently fails to make calls.

  Agreed.  There is a DOS whereby one party of communication forces
everyone else into the clear, but as long as this fact is well
communicated to all parties, then the conversation will adapt
appropriately.  Probably via jibs against the person who'se
software/firmware is too old.

- --

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 6 Nov 2006 19:27:41 -0500

Just a note that in the end we chose to have the answer use the same m= line
transport as the offer, even if SRTP is chosen, specifically because
everyone thought it was illegal otherwise.  Oh, and it will help get through
middle-boxes that look at SDP and expect the offer/answer to match.  ;)

-hadriel

> Sent: Sunday, November 05, 2006 10:22 PM
> 
> Dan Wing wrote:
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 06 Nov 2006 19:45:09 -0500

Hadriel Kaplan wrote:

>everyone thought it was illegal otherwise. 
>
There doesn't seem to be any text anywhere outlawing such behavior. 
However, I'm not as concerned about syntax as semantics.

> Oh, and it will help get through
True, however it will be problematic if such middle-boxes actually use 
the information for anything, e.g. authorize QoS (ande not knowing there 
will be an additional MAC overhead), a firewall or other deep packet 
inspection engine actually looking at the resulting media stream etc. In 
the absence of an additonal O/A exchange with the actual negotiated 
media stream parameters (which I'm not advocating as a requirement, 
albeit it may be helpful as an optional procedure), this of course may 
be an issue for either alternative. I still think it's important that 
the signaling messages exchanged clearly indicate what is going on, and 
my preference would be to have the m= lines reflect as closely as 
possible what the state of affairs actually is, but we are getting into 
a detailed design question where each alternative has pros and cons.

-- Flemming

>>>I understood Francois was pointing out the difference in the m-lines of
>>>      
>>>
>>the
>>    
>>
>>>offer, not the answer.
>>>
>>>I don't care much, myself, if the answer's m-line shows the RTP profile
>>>      
>>>
>>the
>>    
>>
>>>Hadriel, and I exchanged email a month ago that the offerer's RTP profile
>>>      
>>>
>>in
>>    
>>
>>>his m-line doesn't need to match the answerer's RTP profile in his m-
>>>      
>>>
>>line:
>>    
>>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 7 Nov 2006 00:45:45 -0500

> Sent: Monday, November 06, 2006 7:45 PM
> 
> Hadriel Kaplan wrote:
> 

Indeed, that was our argument back to everyone else!  
But in the end we decided it was better to avoid having the same debate with
everyone and not do it to begin with.

> inspection engine actually looking at the resulting media stream etc. 

Au contraire.  Having the term "SAVP" no more helps a middle-box determine
bandwidth/packet-size than "AVP".  Whether the authentication tag is in the
RTP or not, and its length, depends on the transform used; and whether the
MKI is present or not, and its length, depends on the signaling.  There are
other packet size modifying things going on in AVT that will not be new m=
line transports, but rather attributes, as well.

A middle-box would either have to understand those, or the UA would have to
signal the bandwidth explicitly, or the middle-box would have to always give
"slack".

> In

But I thought you weren't as concerned about syntax as semantics.  If so,
then whether the syntax would be "m=...." or "a=...." shouldn't concern you.
;)

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 07 Nov 2006 13:10:21 -0500

Hadriel Kaplan wrote:

>>>Just a note that in the end we chose to have the answer use the same m=
>>>      
>>>
>>line
>>    
>>
>MKI is present or not, and its length, depends on the signaling.  
>
Conversely you could argue that there wouldn't be any reason to look for 
attributes telling you about such things if the "m=" line doesn't say 
you'll actually use an RTP profile where any of that matters. Still, you 
could make it work either way, but I think this is a prime argument for 
why we need to have explicit signaling indication as to exactly what 
semantics we are trying to convey. Trying to infer it based on presence 
or absence of one or more existing attributes with no such semantics 
defined is not a recipe for success IMO.

>There are
>line transports, but rather attributes, as well. A middle-box would either have to understand those, or the UA would have to
Agreed.

>then whether the syntax would be "m=...." or "a=...." shouldn't concern you.
Not being concerned and being concerned to varying degrees are two 
different things :-)

-- Flemming