Source-Specific Multicast for IP
Note: This ballot was opened for revision 07 and is now closed.
(Harald Alvestrand) Discuss
Discuss (2004-10-13 for -** No value found for 'p.get_dochistory.rev' **)
I believe the lack of clarity Spencer noted about ASM/SSM deserves to be addressed. Either it should be known to work or it should be known to not work. Spencer said: 4.1, top of page 7 - This section makes me think ASM listeners won't be able to listen to SSM traffic, but the document doesn't explicitly say so, one way or the other. It's a little less vague on SSM listeners and ASM traffic, but could be clearer here, too. His other comments are worth thinking about, but I don't think they should be blocking.
Comment (2004-10-13 for -** No value found for 'p.get_dochistory.rev' **)
Reviewed by Spencer Dawkins, Gen-ART His review: This document is on the right track, but is still a couple of stops from the end of the line :-) Introduction - The first four paragraphs aren't appropriate for an Introduction - they are fine, but they should be in a following section, by themselves. The fifth paragraph begins a high-level description and justification of SSM - THAT'S what an Introduction should look like. 4.1, top of page 7 - This section makes me think ASM listeners won't be able to listen to SSM traffic, but the document doesn't explicitly say so, one way or the other. It's a little less vague on SSM listeners and ASM traffic, but could be clearer here, too. 4.3 - No justification of the MUST NOT for 188.8.131.52. In general, the justifications in this section are weak, missing, or separated from specific requirements. I'm sure the authors understand all this stuff; the goal is that people who DIDN'T write the document will know how to extend it in the future. 7.1 - points out that SSM can break in the presence of SPI collisions by two senders, but doesn't say whether either senders or receivers can detect this condition automatically - they promise a solution, but don't describe the ability of participants to identify the problem in the meanwhile. 7.1 and 7.3 call out AH - my impression is that the use of AH in standards-track protocols is almost non-existent, and Steve Bellovin keeps telling me that there's no reason for AH. Probably good if these sections aren't too dependent on AH. 7.2 Not sure where "A router MAY have a configuration option to allow source routing" came from - I think this is actually an unintentional use of capitals; surely router requirements for source routing support aren't being specified in the security considerations section of SSM :-) 8 is called "Transition Considerations". What's the vision here - coexistence or transition from ASM to SSM? Is it the same vision in IPv4 and IPv6?
(Bill Fenner) (was Discuss, Yes) Yes
(Allison Mankin) Yes
Comment (2004-10-14 for -** No value found for 'p.get_dochistory.rev' **)
Some other groups (RMT is one) have been eagerly awaiting this. It's clear and well-written. I hope that the IESG discussion will resolve with clarity. If it would be helpful to have some RMT developers who depend on this technology, and intend to use it security features, participate in any discussions, let me know.
(Alex Zinin) Yes
(Steven Bellovin) (was Discuss) No Objection
(Brian Carpenter) (was Discuss) No Objection
(Margaret Cullen) (was Discuss, No Objection) No Objection
(Ted Hardie) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) (was Discuss) No Objection
Overall, I am happy with the update. There is a cut-and-paste problem at the end of the first paragraph in section 7.2. The meaning is unclear.
(David Kessens) No Objection
Comment (2004-10-27 for -** No value found for 'p.get_dochistory.rev' **)
From Pekka Savola, OPS directorate: From 'high view', I think this is OK. The comments in the tracker need to be taken into account. SSM is already out there, and many other related specs already specify a lot of the same things that this spec does, but from a different perspective. As a bigger comment: As a matter of fact, IMHO a lot clarity problems that seem to have come up from those who first read the spec stem from the fact that the specification has been distributed in a large number of documents, and there is substantial overlap. At least these deal with SSM: - 'ssm overview', RFC 3569 - 'ssm architecture', this document - draft-ietf-mboned-ssm232-08.txt [rfc ed queue] - draft-holbrook-idmr-igmpv3-ssm-08.txt [rfc ed queue] - [ draft-ietf-pim-sm-v2-new ] For example, draft-ietf-mboned-ssm232-08.txt specifies much better how the hosts and routers should treat with ASM inside the SSM prefix. I think the reasoning has been that the architecture describes the generic architecture, and protocols or address ranges are described in other documents as they might change a bit more, but I don't think this has entirely successful, because the architecture has ended up also discussing the protocols and numbers a lot, which was not the original intent AFAICS. I'm not sure how to fix this properly, and whether it's even worth fixing up properly, but one option (if it's deemed useful, personally this might be beyond the point of diminishing returns already) might be using more normative references to the abovementioned specs, and making this spec as barebones as reasonable. ... It has been at least a year since I last looked at this, and only skimming now, two comments: 4.3. Allocation of Source-Specific Multicast Addresses The SSM destination address 184.108.40.206 is reserved, and a system MUST NOT send a datagram with a destination address of 220.127.116.11. ==> this seems bogus and should probably be removed. We don't restrict hosts from sending packets to address 0.0.0.0, 18.104.22.168 or a number of other clearly invalid addresses either, but this seems to be wrong place to specify that such transmissions must be prevented. And how would that even be implemented -- should the hosts be able to send packets to 22.214.171.124 using raw sockets? As a suggestion, just say: The SSM destination address 126.96.36.199 is reserved, and it must not be used as a destination address. ... A host operating system SHOULD provide an interface to allow an application to request a unique allocation of a channel destination address in advance of a session's commencement, and this allocation database SHOULD persist across host reboots. ==> a worthy goal, but I don't know any implementation which is providing such an interface.. well, this stuff can probably be removed if this spec is ever pushed forward to draft standard.. nits: - there are a large number of improperly used uppercase keywords - s/RFC2373/RFC3513/ - s/FF3x:3FFF:FFFF/FF3x::3FFF:FFFF/