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

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

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-mcast-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-mcast-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