Re: Some late comments on: draft-ietf-rmt-sec-discussion
Brian Adamson <[email protected]> Fri, 30 Nov 2012 12:51:45 -0500
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
--===============8627022145268568136==
Content-Type: multipart/alternative; boundary="Apple-Mail=_06A8A770-6F52-4DE5-8FD3-210A044618F0"
--Apple-Mail=_06A8A770-6F52-4DE5-8FD3-210A044618F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
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 =
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. =20
####
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]> =
wrote:
>=20
> I have quite a few late comments on this draft, which I hope may be =
helpful.
>=20
> 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.
>=20
> Detailed comments below - typed quickly, so hope they are clear.
>=20
> Gorry
--Apple-Mail=_06A8A770-6F52-4DE5-8FD3-210A044618F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Gorry, et al,<div><br></div><div>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.</div><div><br></div><div><br></div><div>Sorry for the slow =
turn-around on this. We should do another WG last call on this =
before submission =
=85</div><div><br></div><div><br></div><div><br></div><div><div =
style=3D"margin: 0px; font-size: 12px; ">####</div><div style=3D"margin: =
0px; font-size: 12px; ">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?</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done.</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">Section =
1.</div><div style=3D"margin: 0px; font-size: 12px; ">"CDP" is a =
well-known, although proprietary, networking term.</div><div =
style=3D"margin: 0px; font-size: 12px; ">- 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.</div><div style=3D"margin: 0px; =
font-size: 12px; ">- At some places the document speaks about "reliable =
multicast transport</div><div style=3D"margin: 0px; font-size: 12px; =
"> protocol", which may be the same - which may be =
preferable?</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b>Done.</b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">"o Protocol stack available at both ends: A solution that =
requires</div><div style=3D"margin: 0px; font-size: 12px; =
"> some unusual features within the protocol stack will =
not always be"</div><div style=3D"margin: 0px; font-size: 12px; ">- Is =
the word "unusual" really correct here, I suspect the word is =
"specific"?</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done</i></b>.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">"SSM =
routing"</div><div style=3D"margin: 0px; font-size: 12px; ">- shouldn't =
the multicast routing spec also be referenced here?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done</i></b>.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">" =
IGMP/MLD with security =
extensions)."</div><div style=3D"margin: 0px; font-size: 12px; ">- =
Expand IGMP and MLD when first used, (rather than afterwards in sect. =
3.1)</div><div style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done</i></b>.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">" =
TESLA requires a loose time synchronization between the =
source"</div><div style=3D"margin: 0px; font-size: 12px; ">- Expand =
TESLA, and provide ref when first used.</div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; "><b><i>Done</i></b>.</div><div style=3D"margin: =
0px; font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">"multicast routing protocol messaging"</div><div style=3D"margin: =
0px; font-size: 12px; ">- I'm curious, is routing considered more than =
PIM-SM?</div><div style=3D"margin: 0px; font-size: 12px; ">- 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.</div><div style=3D"margin: 0px; font-size: 12px; ">- Is =
there any general guidance on multicast routing security that should be =
referenced?</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>changed to "routing protocol messaging" and added reference to =
Baltatu00 paper.</i></b></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">"For example, reverse-path checks</div><div style=3D"margin: =
0px; font-size: 12px; "> can significantly limit =
opportunities for attackers to conduct replay</div><div style=3D"margin: =
0px; font-size: 12px; "> attacks when hosts actually do use =
IPsec."</div><div style=3D"margin: 0px; font-size: 12px; ">- 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.</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>The =
example of RPF helping reduce replay attack was made more clear by not =
mentioning IPSec.</i></b></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">section 3.1</div><div style=3D"margin: 0px; font-size: 12px; ">" =
consider providing security mechanism"</div><div style=3D"margin: 0px; =
font-size: 12px; =
"> =
^</div><div =
style=3D"margin: 0px; font-size: 12px; ">- insert "a"?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done</i></b>.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">section 3.1.1</div><div style=3D"margin: 0px; font-size: 12px; ">- =
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.</div><div style=3D"margin: 0px; font-size: 12px; =
">- Is RFC 5374 or some other RFC also useful as a ref?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done</i></b>.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">section 3.1.2</div><div style=3D"margin: 0px; font-size: 12px; ">" =
This may be done at intermediate</div><div style=3D"margin: 0px; =
font-size: 12px; "> locations in the network or by hosts =
co-resident with the authorized</div><div style=3D"margin: 0px; =
font-size: 12px; "> hosts on local area networks."</div><div =
style=3D"margin: 0px; font-size: 12px; ">- 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?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>Done - =
omitted the confusing "intermediate locations" portion of the =
example</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">section =
3.2.1</div><div style=3D"margin: 0px; font-size: 12px; ">"than what is =
possible with rogue "</div><div style=3D"margin: 0px; font-size: 12px; =
">- suggest rephrase: "to that possible with rogue"</div><div =
style=3D"margin: 0px; font-size: 12px; ">" similar measures =
used to protect the network from such attacks"</div><div style=3D"margin: =
0px; font-size: 12px; ">- is there a reference to these =
measures?</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done. Added reference to RFC 4732.</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">####</div><div =
style=3D"margin: 0px; font-size: 12px; ">section 3.2.1</div><div =
style=3D"margin: 0px; font-size: 12px; ">" protection =
mechanisms support IP Multicast SHOULD be considered."</div><div =
style=3D"margin: 0px; font-size: 12px; ">- 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".</div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; "><b><i>Done - caps SHOULD =
removed</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">"Sender =
message spoofing attacks are applicable"</div><div style=3D"margin: 0px; =
font-size: 12px; ">- Is the word "applicable" correct here?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>Changed =
to "relevant to"</i></b></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">"Without an authentication mechanism, an attacker can easily =
generate"</div><div style=3D"margin: 0px; font-size: 12px; ">- The words =
"easily generate" ... seems like a judgement, is it really that easy, =
would be wiser to identify the vulnerability?</div><div style=3D"margin: =
0px; font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; "><b><i>removed the word =
"easily"</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">"And =
with FEC-based transport"</div><div style=3D"margin: 0px; font-size: =
12px; ">- possibly better not to start a sentence with "And".</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>Done - =
removed leading "And"</i></b></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">"corrupted FEC payload could potentially render an entire block =
of</div><div style=3D"margin: 0px; font-size: 12px; =
"> transported data invalid."</div><div style=3D"margin: 0px; =
font-size: 12px; ">- could or "would"?</div><div style=3D"margin: 0px; =
font-size: 12px; ">- so this amplifies the effect of inducing =
loss/corruption.</div><div style=3D"margin: 0px; font-size: 12px; ">- =
This applies to NAY packet-based FEC scheme, multicast or =
unicast.</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done - changed to read "would render"</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">####</div><div =
style=3D"margin: 0px; font-size: 12px; ">"In the case of the layered =
congestion control</div><div style=3D"margin: 0px; font-size: 12px; =
"> mechanisms proposed for ALC use, this could lead to the =
receivers</div><div style=3D"margin: 0px; font-size: 12px; =
"> erroneously leaving groups associated with higher =
bandwidth transport</div><div style=3D"margin: 0px; font-size: 12px; =
"> layers and suffering unnecessarily low transport =
rates."</div><div style=3D"margin: 0px; font-size: 12px; ">- True, but =
may be it is important to say that this is safe from a network transport =
perspective.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; "><b><i>Done - additional perspective added.</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; =
">"Similarly,</div><div style=3D"margin: 0px; font-size: 12px; =
"> receivers may be misled to join inappropriate groups =
directing</div><div style=3D"margin: 0px; font-size: 12px; =
"> unwanted traffic to their part of the network."</div><div =
style=3D"margin: 0px; font-size: 12px; ">- can you explain =
more?</div><div style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>Sentence =
reworded to be clearer.</i></b></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">3.2.2. Sender Message Spoofing</div><div style=3D"margin: =
0px; font-size: 12px; ">- What are the mitigations?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">Added note and =
reference to relevant Technological Building Blocks discussion =
section.</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
">####</div><div style=3D"margin: 0px; font-size: 12px; ">3.2.3. =
Receiver Message Spoofing</div><div style=3D"margin: 0px; =
font-size: 12px; ">"In the</div><div style=3D"margin: 0px; font-size: =
12px; "> NORM protocol, this includes =
negative-acknowledgement (NACK) messages"</div><div style=3D"margin: =
0px; font-size: 12px; ">- True, but I thought this is one use-case of =
NORM.</div><div style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>I don't =
understand this comment.</i></b></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">3.2.4. Replay Attacks</div><div style=3D"margin: 0px; =
font-size: 12px; ">" The infamous "replay attack""</div><div =
style=3D"margin: 0px; font-size: 12px; ">-Maybe written a little more =
moderately perhaps?</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; "><b><i>Done - unnecessary "infamy" removed</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">###</div><div =
style=3D"margin: 0px; font-size: 12px; ">3.2.4.1. Replay of Sender =
Messages</div><div style=3D"margin: 0px; font-size: 12px; =
"> Generally, replay of recent protocol messages from the =
sender will</div><div style=3D"margin: 0px; font-size: 12px; ">- true, =
sicne this is usually built on UDP, then this follows, could ref RFC =
5405.</div><div style=3D"margin: 0px; font-size: 12px; ">- doe methods =
like TESLA interact with this?</div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; "><b><i>Referencing RFC 5405 elsewhere is a good =
idea, but 5405 doesn't mention replay issues</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">###</div><div =
style=3D"margin: 0px; font-size: 12px; ">3.2.4.2. Replay of =
Receiver Messages</div><div style=3D"margin: 0px; font-size: 12px; =
">"adding latency to the reliable transport process."</div><div =
style=3D"margin: 0px; font-size: 12px; ">- 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.</div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; "><b><i>Added latency can impact application =
utility.</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">###</div><div style=3D"margin: 0px; font-size: 12px; ">Section =
4.</div><div style=3D"margin: 0px; font-size: 12px; ">"network =
protection"</div><div style=3D"margin: 0px; font-size: 12px; ">- I =
didn't quite grasp what the issue was, is it denial of service to the =
user or some other user- or more?</div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">Section 4.1</div><div style=3D"margin: 0px; font-size: 12px; ">" =
attacker should not be able to damage the whole =
infrastructure by"</div><div style=3D"margin: 0px; font-size: 12px; ">- =
omit "whole"?</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; "><b>Done.</b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">"Unfortunately, recent</div><div style=3D"margin: 0px; font-size: =
12px; "> past has shown that the multicast routing =
infrastructure is</div><div style=3D"margin: 0px; font-size: 12px; =
"> relatively fragile, as well as the applications built on =
top of it."</div><div style=3D"margin: 0px; font-size: 12px; ">- =
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.</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b>Done.</b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">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?</div><div =
style=3D"margin: 0px; font-size: 12px; ">- perhaps this could be =
resolved by moving some of the issues relating to RMT to the next =
section?</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; "><b>Done. The mention of fragile multicast routing infrastructure =
was removed, keeping the focus on RMT issues.</b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
">####</div><div style=3D"margin: 0px; font-size: 12px; ">" Since the =
RMT protocols may use congestion control mechanisms to"</div><div =
style=3D"margin: 0px; font-size: 12px; ">- "may" --- or is it =
stronger?</div><div style=3D"margin: 0px; font-size: 12px; ">- Perhaps =
safer to say:"The congestion control mechanisms in RMT</div><div =
style=3D"margin: 0px; font-size: 12px; ">Protocols regulate, .. etc =
..."</div><div style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>Done - =
"may" removed.</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">"4.2. =
Protocol Protection</div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; "> Protecting the protocols is also of =
importance, since the higher the</div><div style=3D"margin: 0px; =
font-size: 12px; "> number of clients, the more serious the =
consequences of an attack.</div><div style=3D"margin: 0px; font-size: =
12px; "> This is all the more true as scalability is often =
one of the desired</div><div style=3D"margin: 0px; font-size: 12px; =
"> goals of CDP. Ideally, receivers should be =
sufficiently isolated</div><div style=3D"margin: 0px; font-size: 12px; =
"> from one another, so that a single misbehaving receiver =
does not</div><div style=3D"margin: 0px; font-size: 12px; =
"> affect others. Similarly, an external attacker =
should not be able to</div><div style=3D"margin: 0px; font-size: 12px; =
"> break the system, i.e., resulting in unreliable operation =
or delivery</div><div style=3D"margin: 0px; font-size: 12px; =
"> of incorrect content."</div><div style=3D"margin: 0px; =
font-size: 12px; ">- Seems somewhat vague. I am not sure what this =
really says....</div><div style=3D"margin: 0px; font-size: 12px; ">- =
Suggest you point to RFC5405, etc and say what else from an RMT-specific =
viewpoint needs to be addressed.</div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; "><b><i>Done - Clarified to indicated that =
protection of protocol _operation_ is what is highlighted here. =
And a reference to RFC 5405 was added.</i></b></div><div style=3D"margin: =
0px; font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">4.3</div><div style=3D"margin: 0px; font-size: 12px; ">" any =
attacker can easily inject spurious traffic in an ongoing =
NORM"</div><div style=3D"margin: 0px; font-size: 12px; ">- 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?</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">"In that case =
this goal is not the responsibility of the</div><div style=3D"margin: =
0px; font-size: 12px; "> content provider but the =
responsibility of the administrator who</div><div style=3D"margin: 0px; =
font-size: 12px; "> deploys the RMT system itself."</div><div =
style=3D"margin: 0px; font-size: 12px; ">- I'm not sure who is intended =
here?</div><div style=3D"margin: 0px; font-size: 12px; ">- The protocol =
implement ?</div><div style=3D"margin: 0px; font-size: 12px; ">- Would =
multi-party IPsec help?</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; "><b><i>Discussion simplified and clariified - (may need some more =
work here)</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">4.4. =
Privacy</div><div style=3D"margin: 0px; font-size: 12px; ">"The =
situation is different if we consider</div><div style=3D"margin: 0px; =
font-size: 12px; "> receivers since their address should not =
be disclosed publicly."</div><div style=3D"margin: 0px; font-size: 12px; =
">- Often a good goal: Is this ALWAYS the case?</div><div style=3D"margin:=
0px; font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin:=
0px; font-size: 12px; "><b><i>Text clarified.</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">###</div><div =
style=3D"margin: 0px; font-size: 12px; ">" routers to join =
or leave IP multicast session. "</div><div style=3D"margin: 0px; =
font-size: 12px; =
"> =
&n=
bsp; ^</div><div style=3D"margin: 0px; font-size: 12px; =
">-insert "an".</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><b></b><br></div><div style=3D"margin: 0px; =
font-size: 12px; "><b><i>Done</i>.</b></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">" responses, but enables the router to keep track =
of"</div><div style=3D"margin: 0px; font-size: 12px; ">- =
/keep/explicitly/</div><div style=3D"margin: 0px; font-size: 12px; =
">"status on a link"</div><div style=3D"margin: 0px; font-size: 12px; =
">- /link/local network/</div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; "><b><i>Done</i>.</b></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">" including receivers' IP addresses should be =
carefully treated"</div><div style=3D"margin: 0px; font-size: 12px; ">- =
true, but receiver addresses are the to me exactly the same as unicast =
IP addresses, so this is not a unicast-specific issue.</div><div =
style=3D"margin: 0px; font-size: 12px; ">- 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.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><b><i></i></b><br></div><div style=3D"margin: 0px; =
font-size: 12px; "><b><i>Agreed that this is not multicast-specific, but =
worth mentioning either way.</i></b></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; ">"unauthorized users may spoof IGMP/MLD</div><div style=3D"margin: =
0px; font-size: 12px; ">query messages and trace receivers' addresses on =
the same LAN."</div><div style=3D"margin: 0px; font-size: 12px; ">- =
actually that are sahred by the same L2 infrastructure.</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">####</div><div =
style=3D"margin: 0px; font-size: 12px; ">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.</div><div style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>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?)</i></b></div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">####</div><div =
style=3D"margin: 0px; font-size: 12px; ">section 6</div><div =
style=3D"margin: 0px; font-size: 12px; ">"Each of them is now quickly =
discussed"</div><div style=3D"margin: 0px; font-size: 12px; ">- /them is =
now quickly discussed/these is briefly discussed below/</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; ">"what service =
it can offer'</div><div style=3D"margin: 0px; font-size: 12px; ">- /what =
service it can offer/the services it offers/</div><div style=3D"margin: =
0px; font-size: 12px; min-height: 14px; "><b><i></i></b><br></div><div =
style=3D"margin: 0px; font-size: 12px; "><b><i>Done and =
done.</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">"or a =
Global Positioning System (GPS) device"</div><div style=3D"margin: 0px; =
font-size: 12px; ">- better to say a central time source and not to =
refer to one system, rather to give GPS as an example.</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><b><i></i></b><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Done.</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">Section =
6.5</div><div style=3D"margin: 0px; font-size: 12px; ">" This form of =
multicast has group</div><div style=3D"margin: 0px; font-size: 12px; =
"> management benefits since a source can independently =
control the</div><div style=3D"margin: 0px; font-size: 12px; =
"> "channels" it creates."</div><div style=3D"margin: 0px; =
font-size: 12px; ">- I think the current guidance is wrong!</div><div =
style=3D"margin: 0px; font-size: 12px; "> <b><i>Not =
sure exactly what you mean here?</i></b></div><div style=3D"margin: 0px; =
font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">- Actually I really do not understand this. =
While SSM can simplify the routing infrastructure, this seems like it is =
not well expressed here.</div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">- 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.</div><div =
style=3D"margin: 0px; font-size: 12px; "><b><i> - A note to this =
effect was added.</i></b></div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">- Finally RPF checks give much more protection than =
typical for unicast, and this makes multicast more secure rather than =
less secure.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">###</div><div style=3D"margin: 0px; font-size: 12px; =
">6.5.1.</div><div style=3D"margin: 0px; font-size: 12px; ">- Surely the =
most significant issue for the RMT *protocol* is that it implies that =
sources must be advertised as well as group addresses.</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><b><i></i></b><br></div><div style=3D"margin: 0px; font-size: 12px; =
"><b><i>Added a sentence noting this.</i></b></div><div style=3D"margin: =
0px; font-size: 12px; min-height: 14px; "><br></div><div style=3D"margin: =
0px; font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: =
12px; "> against multicast routers, in which innumerable =
IGMP/MLD joins are</div><div style=3D"margin: 0px; font-size: 12px; =
"> =
&n=
bsp; &nbs=
p; ^^^^^^^^^^^</div><div style=3D"margin: 0px; font-size: 12px; ">- =
Seems like the wrong word, even if the value can be enumerated. Is the =
word "excessive"?</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><b></b><br></div><div style=3D"margin: 0px; =
font-size: 12px; "><b>Done - changed "innumerable" to =
"excessive"</b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">" Regarding source-based attack, there are some security =
benefits in</div><div style=3D"margin: 0px; font-size: 12px; =
"> SSM. Since data-plane traffic for an SSM "channel" =
is limited to</div><div style=3D"margin: 0px; font-size: 12px; =
"> that of a single, specific source address, it is possible =
that</div><div style=3D"margin: 0px; font-size: 12px; =
"> network intermediate systems may impose mechanism that =
prevent</div><div style=3D"margin: 0px; font-size: 12px; =
"> injection of traffic to the group from inappropriate =
(perhaps</div><div style=3D"margin: 0px; font-size: 12px; =
"> malicious) nodes."</div><div style=3D"margin: 0px; =
font-size: 12px; ">- Disagree strongly.</div><div style=3D"margin: 0px; =
font-size: 12px; ">- 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.</div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">"This can reduce the risk for denial-of-service and</div><div =
style=3D"margin: 0px; font-size: 12px; "> some of the other =
attacks described in this document. While SSM</div><div =
style=3D"margin: 0px; font-size: 12px; "> alone is not a =
complete security solution, it can simplify secure RMT</div><div =
style=3D"margin: 0px; font-size: 12px; =
"> operation."</div><div style=3D"margin: 0px; font-size: =
12px; ">- Again only partially agree - the strength seems really to be =
based on unicast feedback.</div><div style=3D"margin: 0px; font-size: =
12px; min-height: 14px; "><br></div><div style=3D"margin: 0px; =
font-size: 12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; =
">"establishing all SPTs with no intellectual"</div><div style=3D"margin: =
0px; font-size: 12px; ">- intellectual? - this could probably be =
omitted.</div><div style=3D"margin: 0px; font-size: 12px; min-height: =
14px; "><br></div><div style=3D"margin: 0px; font-size: 12px; =
">####</div><div style=3D"margin: 0px; font-size: 12px; ">"What is =
worse</div><div style=3D"margin: 0px; font-size: 12px; "> is =
that these multicast routers cannot recognize the original =
router</div><div style=3D"margin: 0px; font-size: 12px; =
"> that is attacked and cannot stop the attack =
itself."</div><div style=3D"margin: 0px; font-size: 12px; ">- doesn't =
seem clear, and isn't a RMT-specific issue (please say this).</div><div =
style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>The =
above 3 comments were addressed by removing Section 6.5.3 and simply =
referencing RFC4609 for SSM security considerations. =
</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">####</div><div style=3D"margin: 0px; font-size: 12px; ">Section =
9</div><div style=3D"margin: 0px; font-size: 12px; ">- 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.</div><div style=3D"margin: 0px; font-size: 12px; min-height: 14px; =
"><br></div><div style=3D"margin: 0px; font-size: 12px; "><b><i>Done - =
all references to specific WGs were omitted and reworded / generalized =
as needed.</i></b></div><div style=3D"margin: 0px; font-size: 12px; =
min-height: 14px; "><br></div><div style=3D"margin: 0px; font-size: =
12px; ">###</div></div><div><br><div><div>On Mar 26, 2012, at 1:46 PM, =
Gorry Fairhurst <<a =
href=3D"mailto:[email protected]">[email protected]</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><br>I have quite a few late comments on this draft, which =
I hope may be helpful.<br><br>Overall this seems like a useful document, =
but at several places I had the following concerns:<br>* 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.<br>* In places it passes judgments on things, which I am not =
sure have full IETF consensus, and may probably be better =
reworded.<br><br>Detailed comments below - typed quickly, so hope they =
are clear.<br><br>Gorry<br></blockquote></div><br></div></body></html>=
--Apple-Mail=_06A8A770-6F52-4DE5-8FD3-210A044618F0--
--===============8627022145268568136==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt
--===============8627022145268568136==--