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

[Brian Adamson <[e-mail]>]

OK - thanks for the clarification.  I will make a note to add that qualification to the statement when we revisit this.

cheers,

Brian

On Nov 30, 2012, at 1:18 PM, Gorry Fairhurst <[e-mail]> wrote:

> 
> 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 …
>> 
>> 
>> 
>> ####
>> 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./*
>> 
>> ###
>> 
>> On Mar 26, 2012, at 1:46 PM, Gorry Fairhurst <[e-mail]
>> <mailto:[e-mail]>> 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
>> 
>