Re: [secdir] Status of draft-ietf-l2vpn-vpls-mcast-reqts?

["Yuji KAMITE" <[e-mail]>]

Hi Mark, Tim,

Previously I sent you the proposed changes for the next -08 revision
about security issues, but I haven't submitted it yet publicly.

Could you tell me if I should post it right now to have your IESG review again,
or I should wait for a while before submission.

Best regards,
Yuji


> -----Original Message-----
> From: Yuji KAMITE [mailto:[e-mail]] 
> Sent: Tuesday, November 25, 2008 8:48 PM
> To: 'Tim Polk'
> Cc: [e-mail]; [e-mail]; 'Mark Townsley'; 
> [e-mail]; 
> [e-mail]
> Subject: RE: Status of draft-ietf-l2vpn-vpls-mcast-reqts?
> 
> Hi Tim (CC: Sec-Dirs),
> 
> > I will keep an eye out for the new text, and would be glad 
> to review 
> > it.
> 
> For addressing your DISCUSSes and Sec-Dir comments about this 
> document, I am thinking about revising as attached.
> 
> In your review you pointed out that the current document 
> lacks of thorough security analysis, so now I propose the 
> text to address it.
> 
> I'd appreciate your recheck if it addresses the points you raised.
> For detail, please see the attached text.  I also send the 
> diff-file for your convenience.
> 
> Best regards,
> -Yuji
> 
> ------------------------------
> Proposed changes summary:
>  - Modified Section 6.6.
>       - Create subsection 6.6.1 for security threat analysis : 
>         - This is totally new text for addressing Sam's 
> DISCUSS and Sec-Dir comment below:
>           
> https://datatracker.ietf.org/idtracker/draft-ietf-l2vpn-vpls-m
> cast-reqts/comment/75905/
>           
> http://www.ietf.org/mail-archive/web/ietf/current/msg49004.html
> 
>       - Create subsection 6.6.2. for security requirements:  
>         - Added a short paragraph to show highlighted 
> relationship to address the Tim's DISCUSS
>           
> https://datatracker.ietf.org/idtracker/draft-ietf-l2vpn-vpls-m
> cast-reqts/comment/78677/
>         - Elaborated how each threat item is solved/mitigated 
> 
>  - Modified Section 7.
>       - Added text as 3rd paragraph to reflect the proposed 
> changes in Section 6.6.
> ------------------------------
> 
> 
> > -----Original Message-----
> > From: Tim Polk [mailto:[e-mail]]
> > Sent: Tuesday, November 18, 2008 4:55 AM
> > To: Yuji KAMITE
> > Cc: 'Mark Townsley';
> > [e-mail];
> > [e-mail]
> > Subject: Re: Status of draft-ietf-l2vpn-vpls-mcast-reqts?
> > 
> > Hi Yuji,
> > 
> > I will keep an eye out for the new text, and would be glad 
> to review 
> > it.
> > 
> > Thanks,
> > 
> > Tim
> > 
> > On Nov 17, 2008, at 10:36 AM, Yuji KAMITE wrote:
> > 
> > > Mark,
> > >
> > > Regarding Tim's comment,
> > > I've been writing up the security threat analysis recently, but 
> > > couldn't submit before the deadline.
> > > I'd like to show the curent proposed text for security 
> very soon.  
> > > (Hopefully in this week.) I hope Tim will take a look at it.
> > >
> > > BTW, regarding Ron's comment,
> > > I did the changes to address his comment already.
> > > But not sure if he actually confirmed it.
> > >
> > > Regards,
> > > Yuji
> > > -----Original Message-----
> > > From: Mark Townsley [mailto:[e-mail]]
> > > Sent: Monday, November 17, 2008 9:40 AM
> > > To: [e-mail];
> > > [e-mail]
> > > Subject: Status of draft-ietf-l2vpn-vpls-mcast-reqts?
> > >
> > >
> > >
> > > My notes say:
> > >> 2 issues mostly covered, remaining security threat 
> analysis issue 
> > >> taking more time.
> > > I assume this means the comment from Ron can be argued 
> against, but 
> > > that the security issue is more problematic.
> > >
> > > The document hasn't moved since the last IETF. It seems stuck and 
> > > needs a little attention from someone.
> > >
> > > Authors, please try and sit down with Tim Polk this week
> > and resolve
> > > what needs to be done to move this document forward. If 
> you need my 
> > > help, please ask.
> > >
> > > Thanks,
> > >
> > > - Mark
> > >
> > >
> > >> Discusses and Comments
> > >> Ron Bonica:
> > >> Discuss:
> > >> [2007-12-20] Maybe I missed it, but the document doesn't seem to 
> > >> address MAC learning.
> > >>
> > >> Comment:
> > >> [2007-12-20] You say "
> > >>
> > >> "Furthermore, in some cases, IP service providers might expect 
> > >> operational simplicity of VPLS.  That is, they avoid direct and 
> > >> detailed knowledge of IP routing.  In this case, the multicast 
> > >> delivery mechanism is expected to have not only efficiency
> > but also
> > >> simplicity.  Generally speaking, there is a trade-off between 
> > >> efficiency and simplicity in terms of bandwidth usage and state 
> > >> maintenance, so the optimum trade-off will vary depending on the 
> > >> requirements of each IP service provider."
> > >>
> > >> The argument about "operational simplicity of VPLS" 
> > relative to layer
> > >> 3 service is difficult to support, as instead of "direct
> > and detailed
> > >> knowledge of IP routting", one has to deal with direct and
> > detailed
> > >> knowledge of MAC addresses (including MAC address learning), and 
> > >> layer 2.
> > >>
> > >> Consider removing the entire paragraph
> > >>
> > >>
> > >> Also, you say:
> > >>
> > >>   "A solution SHOULD honor customer multicast domains."
> > >>
> > >>
> > >> Perhaps replace with "A solution SHOULD NOT alter customer
> > multicast
> > >> domains' boundaries", as it is not clear what "honor .. 
> multicast 
> > >> domains"
> > >> really means. Otherwise, clarify what "honor" means.
> > >>
> > >> Also, you say:
> > >>
> > >> "Multicast forwarding restoration time MUST NOT be greater
> > than the
> > >> restoration time of a customer's Layer-3 multicast 
> protocols.  For 
> > >> example, if a customer uses PIM with default 
> configuration, hello 
> > >> hold timer is 105 seconds, and solutions are required to 
> detect a 
> > >> failure no later than this period."
> > >>
> > >> The above mixes *restoration* time at layer 3 with
> > *detection* time
> > >> at the VPLS infrastructure. Does not seems to be correct.
> > >>
> > >>
> > >> Also, you say:
> > >>
> > >> Therefore, in addition to the L2VPN discovery requirements in 
> > >> [RFC4665], a multicast VPLS solution SHOULD provide a 
> method that 
> > >> dynamically allows multicast membership information to be
> > discovered
> > >> by PEs.  Such membership information is, for example, a set of 
> > >> multicast addresses.  What information is provided 
> dynamically is 
> > >> solution specific."
> > >>
> > >>
> > >> This paragraph mixes several issues that should probably be 
> > >> unbundled.
> > >> First of all, unless a solution supports (A), as defined in 3.2, 
> > >> there is little point in PEs' dynamically discovering multicast 
> > >> membership info. So, "SHOULD" be conditioned on supporting (A).
> > >>
> > >> Second in one scenario a PE discovers multicast membership
> > info from
> > >> only the sites connected to that PE, while in another 
> scenario in 
> > >> addition to the previous scenario the PE discovers multicast 
> > >> membership info from other PEs as well. The spec needs to
> > spell out
> > >> what exactly it means by "dynamically allow multicast membership 
> > >> information to be discovered by PEs".
> > >>
> > >> Tim Polk:
> > >> Discuss:
> > >> [2008-03-11] [This is a revised discuss, integrating Sam 
> Hartman's 
> > >> issues and my own into a single discuss to support AD 
> transition.]
> > >>
> > >> This discuss elaborates on issues raised in Steve 
> Hanna's security 
> > >> directorate review; that review also needs to be examined in its 
> > >> entirety.
> > >>
> > >> The following issue from the secdir review is blocking:
> > >>> Unfortunately, the document does not contain a systematic
> > security
> > >>> analysis of the problem. The Security Considerations section 
> > >>> consists of two brief paragraphs. These paragraphs 
> refer to other 
> > >>> sections in the document where security requirements are
> > listed and
> > >>> to RFC 4665, which also lists security requirements. However, I 
> > >>> could not find any methodical threat analysis listing the
> > possible
> > >>> threats relevant to the system and stating which ones are
> > protected
> > >>> against and which are not.
> > >>
> > >>> Without a thorough threat analysis, I have little 
> confidence that 
> > >>> the authors have thought carefully about the possible
> > threats to the
> > >>> system. I would expect this to lead to large gaps in 
> the security 
> > >>> requirements and this seems to be borne out in practice. For 
> > >>> example, there is no discussion of threats due to compromise of 
> > >>> components within the service provider network.
> > >>
> > >>> Even more troublesome, I think that a single node at a
> > customer site
> > >>> (presumably untrusted) can mount dangerous attacks. For
> > example, a
> > >>> node that joins many multicast groups can cause a large 
> amount of 
> > >>> state to be maintained in the L2VPN.
> > >>
> > >> Please provide a threat analysis and please work to address or 
> > >> document the specific security concerns cited.
> > >>
> > >> Section 6.6 provides a list of mechanisms a VPLS solution SHOULD 
> > >> include.  There is no apparent relationship between the
> > requirements,
> > >> and each is listed with a caveat regarding its application
> > (e.g., "if
> > >> examined").  The net effect is that list appears to be
> > nearly empty
> > >> under some circumstances: if multicast IP addresses are
> > not used for
> > >> forwarding, and neither Ethernet multicast control frames or IP 
> > >> multicast control packets are examined, only the first and last 
> > >> bullets would apply.
> > >>
> > >> First, are there implicit relationships that should be
> > highlighted to
> > >> clarify the overall effect? For example, if a VPLS 
> solution always 
> > >> examines either Ethernet multicast control frames or IP 
> multicast 
> > >> control packets, the net effect is very different.  If such 
> > >> relationships exist they should be specifed.
> > >>
> > >> The SHOULD list is followed by several paragraphs with MAY 
> > >> requirements.  Again, the net effect is that a VPLS 
> solution might 
> > >> provide none of these mechanisms.  The security considerations 
> > >> section needs to elaborate on the consequences of a VPLS 
> solution 
> > >> that omits these security mechanisms.
> > >
> > 
> 

_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir