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 |