I _finally_ updated an posted a new version of the RMT Security Discussion that incorporates almost all of Gorry's comments. Below is an annotated version of his comments. I had a question regarding your comment on the NORM receiver message spoofing mention in Section 3.3 as I didn't quite understand the comment.
Sorry for the slow turn-around on this. We should do another WG last call on this before submission …
####
This draft contains a normative language declaration using RFC 2119 keywords, however I do not see the need for this - and keywords are not consistently used. Could this be omitted?
Done.
####
Section 1.
"CDP" is a well-known, although proprietary, networking term.
- This is a little confusing, since CDP is itself a multicast protocol. If possible, I'd prefer the WG to choose a non-ambiguous acronym, especially if this is not already embedded in other published specs.
- At some places the document speaks about "reliable multicast transport
protocol", which may be the same - which may be preferable?
Done.
####
"o Protocol stack available at both ends: A solution that requires
some unusual features within the protocol stack will not always be"
- Is the word "unusual" really correct here, I suspect the word is "specific"?
Done.
####
"SSM routing"
- shouldn't the multicast routing spec also be referenced here?
Done.
####
" IGMP/MLD with security extensions)."
- Expand IGMP and MLD when first used, (rather than afterwards in sect. 3.1)
Done.
####
" TESLA requires a loose time synchronization between the source"
- Expand TESLA, and provide ref when first used.
Done.
####
"multicast routing protocol messaging"
- I'm curious, is routing considered more than PIM-SM?
- If it's PIM, then I think the document should also note the reliance on the UNICAST routing infrastructure for RPF, since this also is a point of failure/attack.
- Is there any general guidance on multicast routing security that should be referenced?
changed to "routing protocol messaging" and added reference to Baltatu00 paper.
####
"For example, reverse-path checks
can significantly limit opportunities for attackers to conduct replay
attacks when hosts actually do use IPsec."
- I'm not sure I agree that's IPsec that helps and that this is clear. Isn't it also true that RPF checks help anyway in reducing source-spoofing. I'm not sure the implications of RPF are clear in this version.
The example of RPF helping reduce replay attack was made more clear by not mentioning IPSec.
####
section 3.1
" consider providing security mechanism"
^
- insert "a"?
Done.
####
section 3.1.1
- presumably the threat of snooping PIM could be mitigated by using secure connections between PIM neighbours, e.g. IPsec between PIM routers, is this worth mentioning.
- Is RFC 5374 or some other RFC also useful as a ref?
Done.
####
section 3.1.2
" This may be done at intermediate
locations in the network or by hosts co-resident with the authorized
hosts on local area networks."
- I'm not sure I understand "intermediate" in this example. It requires the attacker's IP address to be valid on the network segment to which it is connected and that segment to support IGMP/MLD... is there more intended?
Done - omitted the confusing "intermediate locations" portion of the example
####
section 3.2.1
"than what is possible with rogue "
- suggest rephrase: "to that possible with rogue"
" similar measures used to protect the network from such attacks"
- is there a reference to these measures?
Done. Added reference to RFC 4732.
####
section 3.2.1
" protection mechanisms support IP Multicast SHOULD be considered."
- I see an RFC 2119 keyword here, but I don't really see the requirement and I don't actually see what someone reading this needs to do, and what the exceptions may be that require this to be a "SHOULD".
Done - caps SHOULD removed
####
"Sender message spoofing attacks are applicable"
- Is the word "applicable" correct here?
Changed to "relevant to"
####
"Without an authentication mechanism, an attacker can easily generate"
- The words "easily generate" ... seems like a judgement, is it really that easy, would be wiser to identify the vulnerability?
removed the word "easily"
####
"And with FEC-based transport"
- possibly better not to start a sentence with "And".
Done - removed leading "And"
####
"corrupted FEC payload could potentially render an entire block of
transported data invalid."
- could or "would"?
- so this amplifies the effect of inducing loss/corruption.
- This applies to NAY packet-based FEC scheme, multicast or unicast.
Done - changed to read "would render"
####
"In the case of the layered congestion control
mechanisms proposed for ALC use, this could lead to the receivers
erroneously leaving groups associated with higher bandwidth transport
layers and suffering unnecessarily low transport rates."
- True, but may be it is important to say that this is safe from a network transport perspective.
Done - additional perspective added.
"Similarly,
receivers may be misled to join inappropriate groups directing
unwanted traffic to their part of the network."
- can you explain more?
Sentence reworded to be clearer.
####
3.2.2. Sender Message Spoofing
- What are the mitigations?
Added note and reference to relevant Technological Building Blocks discussion section.
####
3.2.3. Receiver Message Spoofing
"In the
NORM protocol, this includes negative-acknowledgement (NACK) messages"
- True, but I thought this is one use-case of NORM.
I don't understand this comment.
####
3.2.4. Replay Attacks
" The infamous "replay attack""
-Maybe written a little more moderately perhaps?
Done - unnecessary "infamy" removed
###
3.2.4.1. Replay of Sender Messages
Generally, replay of recent protocol messages from the sender will
- true, sicne this is usually built on UDP, then this follows, could ref RFC 5405.
- doe methods like TESLA interact with this?
Referencing RFC 5405 elsewhere is a good idea, but 5405 doesn't mention replay issues
###
3.2.4.2. Replay of Receiver Messages
"adding latency to the reliable transport process."
- I'm not clear of the vulnerability. Is this just a latency attack, is it possible that the result is not just decreased goodput, can excessive GRTT conclude that the transfer didn't complete.
Added latency can impact application utility.
###
Section 4.
"network protection"
- I didn't quite grasp what the issue was, is it denial of service to the user or some other user- or more?
####
Section 4.1
" attacker should not be able to damage the whole infrastructure by"
- omit "whole"?
Done.
####
"Unfortunately, recent
past has shown that the multicast routing infrastructure is
relatively fragile, as well as the applications built on top of it."
- Although this could be the assertion of the RMT WG, is this shared by MBONED WG, responsible for deployment? I'd personally suggest some less judgement text, since it doesn't impact the guidance.
Done.
####
I dp not like the way 4.1 speaks of both IP multicast generic and RMT-specific issues. Please can these be placed in separate subsections?
- perhaps this could be resolved by moving some of the issues relating to RMT to the next section?
Done. The mention of fragile multicast routing infrastructure was removed, keeping the focus on RMT issues.
####
" Since the RMT protocols may use congestion control mechanisms to"
- "may" --- or is it stronger?
- Perhaps safer to say:"The congestion control mechanisms in RMT
Protocols regulate, .. etc ..."
Done - "may" removed.
####
"4.2. Protocol Protection
Protecting the protocols is also of importance, since the higher the
number of clients, the more serious the consequences of an attack.
This is all the more true as scalability is often one of the desired
goals of CDP. Ideally, receivers should be sufficiently isolated
from one another, so that a single misbehaving receiver does not
affect others. Similarly, an external attacker should not be able to
break the system, i.e., resulting in unreliable operation or delivery
of incorrect content."
- Seems somewhat vague. I am not sure what this really says....
- Suggest you point to RFC5405, etc and say what else from an RMT-specific viewpoint needs to be addressed.
Done - Clarified to indicated that protection of protocol _operation_ is what is highlighted here. And a reference to RFC 5405 was added.
####
4.3
" any attacker can easily inject spurious traffic in an ongoing NORM"
- How easy and what sort of attack - do they have to be on the multicast distribution tree? on the source path? or anywhere in the network?
"In that case this goal is not the responsibility of the
content provider but the responsibility of the administrator who
deploys the RMT system itself."
- I'm not sure who is intended here?
- The protocol implement ?
- Would multi-party IPsec help?
Discussion simplified and clariified - (may need some more work here)
####
4.4. Privacy
"The situation is different if we consider
receivers since their address should not be disclosed publicly."
- Often a good goal: Is this ALWAYS the case?
Text clarified.
###
" routers to join or leave IP multicast session. "
^
-insert "an".
Done.
####
" responses, but enables the router to keep track of"
- /keep/explicitly/
"status on a link"
- /link/local network/
Done.
####
" including receivers' IP addresses should be carefully treated"
- true, but receiver addresses are the to me exactly the same as unicast IP addresses, so this is not a unicast-specific issue.
- Rather to me, the implication is that operators need to ensure that group membership information is treated responsibly - since this can reveal patterns of usage by specific users.
Agreed that this is not multicast-specific, but worth mentioning either way.
####
"unauthorized users may spoof IGMP/MLD
query messages and trace receivers' addresses on the same LAN."
- actually that are sahred by the same L2 infrastructure.
####
I think this section really needs a summary section, because to me many of these threats are against the IP multicast infrastructure and NOT specifically against RMT.
Done - sentence added in introduction of section that notes that some goals are also common to unicast operation or IP multicast infrastructure. (may need to do this at beginning of document, too?)
####
section 6
"Each of them is now quickly discussed"
- /them is now quickly discussed/these is briefly discussed below/
"what service it can offer'
- /what service it can offer/the services it offers/
Done and done.
####
"or a Global Positioning System (GPS) device"
- better to say a central time source and not to refer to one system, rather to give GPS as an example.
Done.
####
Section 6.5
" This form of multicast has group
management benefits since a source can independently control the
"channels" it creates."
- I think the current guidance is wrong!
Not sure exactly what you mean here?
- Actually I really do not understand this. While SSM can simplify the routing infrastructure, this seems like it is not well expressed here.
- For years we have built ASM applications, and it is great advice to tell receivers to EXPLICITLY FILTER data transfer packets to be only receive from the expected source.
- A note to this effect was added.
- Finally RPF checks give much more protection than typical for unicast, and this makes multicast more secure rather than less secure.
###
6.5.1.
- Surely the most significant issue for the RMT *protocol* is that it implies that sources must be advertised as well as group addresses.
Added a sentence noting this.
####
against multicast routers, in which innumerable IGMP/MLD joins are
^^^^^^^^^^^
- Seems like the wrong word, even if the value can be enumerated. Is the word "excessive"?
Done - changed "innumerable" to "excessive"
####
" Regarding source-based attack, there are some security benefits in
SSM. Since data-plane traffic for an SSM "channel" is limited to
that of a single, specific source address, it is possible that
network intermediate systems may impose mechanism that prevent
injection of traffic to the group from inappropriate (perhaps
malicious) nodes."
- Disagree strongly.
- First, SSM doesn't STOP receivers to send, it simply assigns this to a different group, also as a transport function, you could still use unicast feedback... this really doesn't seem like a routing level concern.
"This can reduce the risk for denial-of-service and
some of the other attacks described in this document. While SSM
alone is not a complete security solution, it can simplify secure RMT
operation."
- Again only partially agree - the strength seems really to be based on unicast feedback.
####
"establishing all SPTs with no intellectual"
- intellectual? - this could probably be omitted.
####
"What is worse
is that these multicast routers cannot recognize the original router
that is attacked and cannot stop the attack itself."
- doesn't seem clear, and isn't a RMT-specific issue (please say this).
The above 3 comments were addressed by removing Section 6.5.3 and simply referencing RFC4609 for SSM security considerations.
####
Section 9
- Suggest you do not refer to specific WGs, it seems inappropriate for a published RFC to cite specific charters or try to direct specific work to as WG.
Done - all references to specific WGs were omitted and reworded / generalized as needed.
###
RSS Feed