RE: Media Security Requirements Draft: New Requirement

["Dan Wing" <dwing@xxxxxxxxx>]

> Hi Christer, 
> 
> I am not sure whether this requirement is directly related to 
> media security (although it impacts it). Would ICE even work 
> if you assume such restrictive middleboxes?

* Such firewalling would also block RSVP.  RSVP is necessary
for prioritized network access for certain user communities 
(GETS/IEPREP on public networks, MLPP on private networks).

* Such firewalling would prevent media path probing, such as
that described in draft-babiarz-pcn-explicit-marking 
and draft-babiarz-pcn-sip-cap.  Such an incrementally-
deployable CAC and path selection technique seems like 
it could be useful.

> In some sense you seem to say that key management for media 
> security has to be done along the signaling path and not 
> along the media path. 
> 
> Do I understand your requirement and your intention properly?

Christer, I wonder if there is any requirement to avoid sending
a ~600 byte public key (or ~600 byte certificate) from the 
endpoint on each call?  This seems like it might be a requirement
for a bandwidth-sensitive network environment, and a mechanism
to avoid that or cache that in the network in some way might
be beneficial (that is, an optimization) or might be necessary.

Thoughts?

-d

> Ciao
> Hannes
> 
> 
> -------- Original-Nachricht --------
> Datum: Tue, 5 Jun 2007 08:55:07 +0200
> Von: "Christer Holmberg (JO/LMF)" <christer.holmberg@xxxxxxxxxxxx>
> An: "Hannes Tschofenig" <Hannes.Tschofenig@xxxxxxx>, 
> ietf-rtpsec@xxxxxxx, "Dan Wing" <dwing@xxxxxxxxx>
> Betreff: RE: Media Security Requirements Draft
> 
> > 
> > 
> > Hi,
> > 
> > In a previous thread (RE: Fwd: I-D
> > ACTION:draft-zimmermann-avt-zrtp-03.txt), when we were discussing
> > middleboxes, Dan proposed a requirement saying something like:
> > 
> > "A solution MUST NOT expect packets to be received on the media path
> > until 200 OK, because the media path will be blocked by middleboxes 
> > until the 200 OK."
> > 
> > (I proposed to change "will be blocked" to "may be blocked")
> > 
> > However, I can't find this requirement in the latest 
> version of the reqs
> > draft.
> > 
> > Regards,
> > 
> > Christer
> >  
> > 
> > > -----Original Message-----
> > > From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> > > [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of 
> Hannes Tschofenig
> > > Sent: 30. toukokuuta 2007 0:33
> > > To: ietf-rtpsec@xxxxxxx
> > > Subject: Media Security Requirements Draft
> > > 
> > > 
> > > Hi all,
> > > 
> > > we have published another version of the requirements draft:
> > > 
> http://tools.ietf.org/id/draft-wing-media-security-requirements-03.txt
> > > 
> > > The changes in the draft are focused on the following requirement:
> > > 
> > > R27:   If SRTP keying is performed over the media path, the keying
> > >            packets MUST NOT pass the RTP validity check defined in
> > >            Appendix A.1 of [RFC3550
> > > <http://www.rfc-editor.org/rfc/rfc3550.txt>]
> > > 
> > > It seems that we are getting to an end with the requirements work.
> > > 
> > > Ciao
> > > Hannes
> > > 
> > >