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

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

cheers,

Brian

On Nov 30, 2012, at 1:18 PM, Gorry Fairhurst <[email protected]> wrote:

> =

> Great - glad they were helpful.
> =

> I think the last "unknown" comment was very trivial and related only to m=
y understanding that you could use NORM without feedback, and hence the vul=
nerability applies when you do have feedback.
> =

> i.e., A use-case with a sender that does not accept feedback from a recei=
ver 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 inten=
ded?
>> =

>> */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 concer=
n.
>> =

>> "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
>> =

> =