Re: Some late comments on: draft-ietf-rmt-sec-discussion

Great - glad they were helpful.

I think the last "unknown" comment was very trivial and related only to =

my understanding that you could use NORM without feedback, and hence the =

vulnerability applies when you do have feedback.

i.e., A use-case with a sender that does not accept feedback from a =

receiver is not vulnerable to attacks using NACK messages, maybe =

similarly also one that only accepts messages from authenticated receivers.

Gorry


On 30/11/2012 17:51, Brian Adamson wrote:
> Gorry, et al,
>
> 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 =85
>
>
>
> ####
> 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 intend=
ed?
>
> */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./*
>
> ###
>
> On Mar 26, 2012, at 1:46 PM, Gorry Fairhurst <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>> I have quite a few late comments on this draft, which I hope may be
>> helpful.
>>
>> Overall this seems like a useful document, but at several places I had
>> the following concerns:
>> * It seems to mix infrastructure and transport issues more than I
>> would have hoped. Separating these so that I could clearly understand
>> what an RMT designer needs to do, and what an operator needs to
>> provide, would be helpful.
>> * In places it passes judgments on things, which I am not sure have
>> full IETF consensus, and may probably be better reworded.
>>
>> Detailed comments below - typed quickly, so hope they are clear.
>>
>> Gorry
>