Subject: mboned: Re: Some questions on draft-ietf-mboned-mroutesec-04.txt

From: Pekka Savola <[email-masked]>
Date: Sun, 30 Apr 2006 10:39:49 +0300 (EEST)

Your message hasn't appeared on the MBONED list, maybe you aren't 
subscribed with that address, and the moderator didn't approve the 
message..

On  Thu, 27 Apr 2006 16:34:39 +0530, Bharat Joshi wrote:
> Hi Pekka,
>
>     I was going through the document and found it really interesting.

Thanks.  However, the document is in RFC editor's queue (almost two 
years now, waiting for the PIM spec and RPsec reference which we 
should move over to informative), so big changes aren't possible.  We 
can easily fix the editorials though.

>     I have couple of questions and suggestions:
>
> * In section 3.2.1, typo "an attacker wishing to overload the RP with
> encapsulated packets or different groups" -> "an attacker wishing to
> overload the RP with encapsulated packets of different groups"

OK.

> * In section 3.2.1, you may want to add the "Generation of Register Stop
> messages in slow path/control plane for different groups" in the list of
> overloading the cpu.

This could be added, but it's probably more than just an editorial 
addition, so I'm not sure if it'd be acceptable.

> * What will happen when a malicious user start sending multicast data
> traffic and its DR has a *,G state on one of its interface? I think it
> will send the traffic to RP and will start forwarding it on this
> interface also. This way a malicious user can disturb the existing
> users.

You probably mean, has (*,G) state on one of its _other_ interfaces? 
By my reading of the spec, yes: section 4.2 includes 
'inherited_olist(S,G,rpt)' which includes the interfaces with (*,G) 
state.

This would probably make a good addition to 3.2.2, but it's 
non-editorial.  It seems rather important one to note though, so I'll 
have to see about it..

> * In section 3.2.2, I did not get fully the meaning of the statement "As
> a result, for this attack to succeed, the RP must decapsulate the
> packets, causing the propagation of data and the integrity violation."
> Could you please help me understand this?

It means that if you send packets to group G via 
register-encapsulation, the RP:
  - does have a possibility for policy checkpoint (whether or not to 
accept register packets, e.g., if register tunnel is protected using 
IPsec or not), and
  - if the packet is accepted, the RP forwards it to the receivers in 
the multicast distribution tree, and this attacker's data violates the 
integrity of the multicast stream.

If you think the language could be improved with an editorial 
clarification, please suggest one :-)

> * In section 4.2, in some of the points "could" is used and in some of
> the points "should" have been used. I feel they all should use "should"
> keyword.

Good point -- some of those were probably intentional though, so I 
fear this would be a non-editorial change.

> * In section 5.1, point 2, did you mean DR instead of RP in statement
> "An additional method could be implementing a timer on the RPs ".

Good catch, I think this can be corrected.

> * In last paragraph of section 5.3, Typo "while not not desiring"

OK.

> * In section 5.3.3, typo in "This would second-order defense againt PIM"
> -> "This would be second-order defense againt PIM"

OK.

> * Can we add definition of "GMP" as "Group Management Protocols"
> somewhere?

I'll rather expand the only use of 'GMP' to 'IGMP/MLD'

> * In section 5.3.4, typo "existing legimate sessions" -> "existing
> legitimate sessions"

OK.

> * I did not find a reference in PIM-SM spec but should an RP simply drop
> a register message if the source IP is not within the same domain?

Probably not -- I mean, the RP has no way of knowing whether a source 
IP address is within its domain or not; this is not communicated in 
any way (which is part of the problem).  Many implementations offer 
access lists etc. for this though, but I'm not sure how many use them 
for this purpose.

If the RP had the notion of its domain, dropping foreign register 
messages would probably be a good idea..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/