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

Brian Adamson <brian.adamson@nrl.navy.mil> Fri, 30 November 2012 17:52 UTC

Return-Path: <brian.adamson@nrl.navy.mil>
X-Original-To: rmt@ietfa.amsl.com
Delivered-To: rmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE52D21F8B2B for <rmt@ietfa.amsl.com>; Fri, 30 Nov 2012 09:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfnaoac5ZpTr for <rmt@ietfa.amsl.com>; Fri, 30 Nov 2012 09:52:16 -0800 (PST)
Received: from mail4.nrl.navy.mil (mail4.nrl.navy.mil [IPv6:2001:480:20:421::587:27]) by ietfa.amsl.com (Postfix) with ESMTP id C94C921F8B14 for <rmt@ietf.org>; Fri, 30 Nov 2012 09:52:15 -0800 (PST)
Received: from [192.168.1.103] (c-76-21-150-94.hsd1.md.comcast.net [76.21.150.94]) (authenticated bits=0) by mail4.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id qAUHpmr4009494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Nov 2012 12:51:50 -0500
From: Brian Adamson <brian.adamson@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_06A8A770-6F52-4DE5-8FD3-210A044618F0"
Message-Id: <C0944BF5-48FB-4CE7-B4F8-0FFABE607CC6@nrl.navy.mil>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Fri, 30 Nov 2012 12:51:45 -0500
References: <4F70AB83.7000808@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk, "rmt@ietf.org" <rmt@ietf.org>
In-Reply-To: <4F70AB83.7000808@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.1499)
X-Scanned-By: MIMEDefang 2.72
X-Mailman-Approved-At: Fri, 30 Nov 2012 10:48:17 -0800
Subject: Re: [Rmt] Some late comments on: draft-ietf-rmt-sec-discussion
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Nov 2012 17:52:27 -0000

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 <gorry@erg.abdn.ac.uk> 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