[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RTPSec BOF proposal for IETF 68
On 20 Jan 2007, at 00:03, Dan Wing wrote:
Lakshminath,
Some notes: IIRC, in Montreal, we ran out of time on getting
opinions on some of the open issues. RTP and RTCP was one that we
dealt with in San Diego (has that been decided?).
If you're referring to keying in the RTP path (DTLS, ZRTP, MIKEYv2)
or RTCP path (EKT), I believe there was consensus that it was okay
to key in the RTP path, with some expressing distaste about its
lack of purity.
The consensus was as follows:
On 22 Nov 2006, at 15:22, Colin Perkins wrote:
The working group chairs met with our area director after the
second AVT session in San Diego to discuss the outcome of the RTP
keying discussion. Two conclusions were identified:
1) We believe the consensus of the working group is that signalling
is not to be conveyed within RTP data packets, but should instead
be sent within some form of control packet.
2) We believe the consensus of the working group is that it is
acceptable to multiplex control and data packets on the same UDP
port, provided the packet types can be clearly distinguished.
Our reading is that the group sees value in a clear architectural
separation of data and control, but is concerned about the overhead
and complexity that is brought about by separating them onto
different ports. We note that neither consensus is unanimous, and
that some in the working group believe efficient transport more
important than architectural purity.
We did not see any consensus on the question of whether keying
information should be conveyed in RTCP packets multiplexed on the
RTP port, or in some other protocol multiplexed on the RTP port.
The opinion of the chairs and area director is that both approaches
are workable, and fit within the RTP architecture, but that it may
be cleaner to use a separate keying protocol (modelled after STUN),
than to try to fit keying within RTCP.
[From http://www1.ietf.org/mail-archive/web/avt/current/msg07544.html]
The AVT working group accepts that control packets need to be
multiplexed on the RTP port, as is done with STUN. There was strong
pushback against the idea of including keying information in RTP data
packets, as done by ZRTP, rather than sending it in a separate
protocol multiplexed on the same port, as done in the DTLS-based
proposals. That separate protocol could be RTCP, or something else
clearly distinguishable from RTP. I interpret "clearly
distinguishable" to be something which fails the RTP packet validity
checks in Appendix A.1 of RFC 3550 if sent to an unsuspecting end
point (as occurs when RTCP and STUN are multiplexed with RTP), as so
will not disrupt normal operation.
Any other open issues anyone recalls?
We have several open issues in draft-wing-media-security-
requirements, and
some issues that are for future study. We are going to update that
document
for the upcoming meeting, as some of the open issues and some of
the text is
not sufficiently clear.
Next, do we have a consensus set of evaluation criteria now to weigh
the solution drafts against? It would be good to publish that soon
in some form (probably as an update to Dan and Francois's draft?)
We need to evaluate protocols based on a consensus of the
requirements for
an Internet protocol. I don't think draft-wing-media-security-
requirements has had sufficient review or consensus yet.
The draft Francois and I wrote (draft-wing-rtpsec-keying-eval) can
be used
to evaluate the proposals against the requirements. We will be
publishing
an update to it for this IETF (delete DTLS-RTP, which has been
dropped by
its authors; clean up some cruft).
It's a unfortunate that compatibility with the RTP architecture isn't
included as an explicit evaluation criteria.
--
Colin Perkins
http://csperkins.org/