Subject: Re: [Srcomp] Analysis: Security requirements

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 9 Feb 2021 02:07:50 +0000

I suddenly find out that the latest revision of the requirement draft is still revision 4, we may need to upload the latest revision draft when we are ready ,which will facilitate the analysis work.

The format that Darren proposes works to me now. Following this format, the brief analysis of security requirements is shown below.

Security Mechanisms

   Requirement: The compression solution SHOULD be able to address security issues that it introduces, using existing security mechanisms.

            +---------------------------------+-------+------+-------+---------+
            |                                                  | CSID | CRH | VSID | UIDSR |
            +---------------------------------+-------+------+-------+---------+
            | Security Mechanisms           |  Yes  |  Yes |  Yes   |   YES    |
            +---------------------------------+-------+------+-------+---------+

   Conclusion: All proposals resolve known security issues.

SR Domain Protection

   Requirement: A compression solution must not require nodes outside the SR domain to know SID values within the SR domain, and it must provide the ability to block nodes outside an SR domain from accessing SIDS.

           +---------------------------------+-------+-------+-------+---------+
           |                                                  | CSID |  CRH | VSID | UIDSR |
           +---------------------------------+-------+-------+- -----+---------+
           | SR Domain Protection         |  Yes  |    Yes |  Yes  |     YES   |
           +---------------------------------+-------+-------+-------+---------+

   Conclusion: All proposals describe how SIDs within the SR domain are  protected.

Thanks,
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Darren Dukes (ddukes)
Sent: Monday, February 8, 2021 2:56 PM
To: Ron Bonica <rbonica=[email-masked]>; srcomp <[email-masked]>
Subject: Re: [Srcomp] Analysis document template

Hey team, I think we will be better off recording analysis in tables with requirement/metric in rows and proposals in columns.  It allows for easier comparison across sets of requirements, and accommodates requirements with many metrics.

Here are a couple example sections, additional analysis details can live in an appendix to keep the main document uncluttered.

Thoughts?

Section: Scalability Requirements

   The compression proposal MUST be capable of representing 65000
   adjacency segments per node.

   The compression proposal MUST be capable of representing 1 million
   prefix segments per SID numbering space.

   The compression proposal MUST be capable of representing 1 million
   services per node.

       +-------------------------------+------+-----+------+-------+
       |                               | CSID | CRH | VSID | UIDSR |
       +-------------------------------+------+-----+------+-------+
       | Adjacency Segment Scale 65000 | Yes  | Yes | Yes  |       |
       | Prefix Segment Scale 1000000  | Yes  | Yes | Yes  |       |
       | Service Scale 1000000         | Yes  | Yes | Yes  |       |
       +-------------------------------+------+-----+------+-------+

   Conclusion: All proposals support 16-bit and 32-bit variants to
   support large scale deployments

Section: SRv6 Base Coexistance

   The compression proposal MUST support deployment in existing SRv6
   networks.

           +-----------------------+------+-----+------+-------+
           |                       | CSID | CRH | VSID | UIDSR |
           +-----------------------+------+-----+------+-------+
           | SRv6 Base Coexistence | Yes  | Yes | Yes  |       |
           +-----------------------+------+-----+------+-------+

   Conclusion: All proposals can be deployed simultaneously with the
   SRv6 base solution.

On 2021-02-03, 2:46 PM, "Srcomp" <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

I have updated the analysis document template, making the following changes:

-          Moved the authors to the front page, in random order. We can re-order them when we know what the order should be.

-          Added a list or proposals.

-          Added partial content for four easy requirements

The partial content includes:

-          A restatement of the requirement

-          A table that indicates whether each proposal is fully, partially, or not compliant

-          A blank section for discussion

I filled out the table for the CRH proposal, because I am very familiar with that one. As we proceed with the analysis phase, the person most familiar with a proposal should fill out the corresponding line of the table. We could then discuss the content during calls.

                                                                                                                   Ron

Juniper Business Use Only