Skip to main content

The Multicast Group Security Architecture
draft-ietf-msec-arch-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Bert Wijnen
2004-01-22
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-01-21
05 Amy Vezza IESG state changed to Approved-announcement sent
2004-01-21
05 Amy Vezza IESG has approved the document
2004-01-21
05 Amy Vezza Closed "Approve" ballot
2004-01-20
05 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::Revised ID Needed by Russ Housley
2004-01-20
05 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2004-01-15
05 (System) New version available: draft-ietf-msec-arch-05.txt
2004-01-13
05 Russ Housley State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Russ Housley
2004-01-08
05 Amy Vezza Removed from agenda for telechat - 2004-01-08 by Amy Vezza
2004-01-08
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-01-08
05 Margaret Cullen
[Ballot comment]
I have the following editorial comment:

  This is true because multicast routing protocols generally require
  the source of an IP multicast …
[Ballot comment]
I have the following editorial comment:

  This is true because multicast routing protocols generally require
  the source of an IP multicast packet to remain unchanged in order to
  create distribution trees.

>> It is not clear to me how the second sentence follows from
>> the third... 

  However, if NAT is deployed in a network
  for IP multicast packets (e.g., between administrative entities),
  then the connectivity of senders and receivers may be adversely
  affected.

>> What is "a network for IP multicast packets"?  And, how is this
>> sentence consistent with the statement that "In general, NAT is
>> not a problem with IP multicast traffic"?
2004-01-08
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-01-08
05 Bert Wijnen
[Ballot comment]
From OPS Directorate (Pekka):


nits:
-----
- there are some references which aren't referred to in the body of
the draft, at least …
[Ballot comment]
From OPS Directorate (Pekka):


nits:
-----
- there are some references which aren't referred to in the body of
the draft, at least RFC3552.
- IPR section should be added, even though it's likely the
architecture document would be subject to such IPR (rather than the
referred methods)
2004-01-08
05 Bert Wijnen
[Ballot discuss]
From OPS Directorate (Pekka)... DISCUSS for now:
Bigger issues:

1) I do not like how this work has "hijacked" the term "multicast
security".  …
[Ballot discuss]
From OPS Directorate (Pekka)... DISCUSS for now:
Bigger issues:

1) I do not like how this work has "hijacked" the term "multicast
security".  There is a lot more to multicast than
authentication/encryption of the application level data, just as there
is a lot more to unicast security than IPsec.

This ambiguity appears to have originated already around 2000 in the
first IRTF drafts.

I wonder if it would be possible to reword the title, from:

The Multicast Security Architecture

to e.g.:

The Multicast Group Security Architecture
(which isn't all that good either, but maybe a bit better.)

.. and make the similar adjustments and add more elaboration on which
actual issues are being addressed in the abstract and the
introduction.

2) Perhaps due to 1).. As an operator, multicast in particular (but
unicast to an extent as well, which is why describing IPsec as "the
security" is inappropriate) suffers from a lot of security problems in
the data and signalling plane, i.e., how the multicast routing
protocols operate and how one joins or sends to groups.

The draft states in the security considerations:
                                                                    As
  such, denial of service, message deletion, and other active attacks
  on the unicast or multicast routing infrastructures are not addressed
  by this framework.

.. which hits is pretty close to the mark.  However, based on that
rather vague statement, it's not clear whether 1) the draft assumes
that the unicast/multicast routing infrastructures are secure (wrong
assumption, causing the whole architecture to fall down if so), or 2) 
the architecture is supposedly designed so that the underlying
architecture is transparent and do not affect the multicast
architecture described in this memo (also an unbearable situation).

I don't think it's necessary, in this document, to describe and fix
the issues in unicast/multicast routing infrastructures, but these
have important implications to the proposed application-level
multicast security architecture (e.g., in the form of DoS attacks)..
and might warrant some analysis or elaboration of the remainder
threats.

3) I assume the "difficult stuff", that is:
- user <-> policy-server authentication and trust issues
(small-scale PKI-level problems I think?) and
- policy-server <-> policy server mutual trust (can they be in
different adminsitrative domains, for example?)

.. will be discussed at more length in the actual protocol
documents..?
2004-01-08
05 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Undefined by Bert Wijnen
2004-01-08
05 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2004-01-08
05 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2004-01-08
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2004-01-08
05 Ted Hardie
[Ballot comment]
Nit:  In section 4.2, there is a bounding box around figure 3.  Since 3a and 3b represent
different set relationships, having a bound …
[Ballot comment]
Nit:  In section 4.2, there is a bounding box around figure 3.  Since 3a and 3b represent
different set relationships, having a bound box around the whole is confusing (as it looks
like a set containing the sets in 3a and 3b).  If others find it similarly confusing,
I'd suggest splitting 3a and 3b out of the box.
2004-01-08
05 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2004-01-07
05 Steven Bellovin [Ballot comment]
Some of the informative references are to very old IDs.  draft-balenson-groupkeymgmt-oft is probably the worst; it's from 1999...
2004-01-07
05 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin
2003-12-20
05 Ned Freed [Ballot comment]
Nits: No copyright, IPR boilerplate
2003-12-20
05 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-12-17
05 Russ Housley State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley
2003-12-17
05 Russ Housley Status date has been changed to 2003-12-17 from 2003-11-25
2003-12-17
05 Russ Housley Placed on agenda for telechat - 2004-01-08 by Russ Housley
2003-12-17
05 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2003-12-17
05 Russ Housley Ballot has been issued by Russ Housley
2003-12-17
05 Russ Housley Created "Approve" ballot
2003-12-09
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2003-11-25
05 Amy Vezza Last call sent
2003-11-25
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-25
05 Russ Housley Status date has been changed to 2003-11-25 from 2003-09-21
2003-11-25
05 Russ Housley State Changes to Last Call Requested from AD Evaluation by Russ Housley
2003-11-25
05 Russ Housley Last Call was requested by Russ Housley
2003-11-25
05 (System) Ballot writeup text was added
2003-11-25
05 (System) Last call text was added
2003-11-25
05 (System) Ballot approval text was added
2003-11-25
04 (System) New version available: draft-ietf-msec-arch-04.txt
2003-09-21
05 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2003-09-21
05 Russ Housley Draft Added by Russ Housley
2003-08-15
03 (System) New version available: draft-ietf-msec-arch-03.txt
2003-07-30
02 (System) New version available: draft-ietf-msec-arch-02.txt
2003-05-08
01 (System) New version available: draft-ietf-msec-arch-01.txt
2003-03-25
00 (System) New version available: draft-ietf-msec-arch-00.txt