RE: Comments on draft-zhao-opsec-routing-capabilities-02.txt

[Zhao Ye <yezhao@huawei.com>]

> 1.2. Capabilities versus Requirements
> 
>    Capabilities may or may not be requirements. That is a local
>    determination that must be made by each operator with reference to
>    the policies that they must support. It is hoped that this 
> document,
>    together with [OSCP] will assist operators in identifying their
>    security capability requirements and communicating them clearly to
>    vendors.
> 
> ...
> gmj> We need a standard text for this section to be used in all
> capability drafts.
> gmj> I will work on this.
> ...

Ok, waiting for your normative description.

> 2. Route Filtering Capabilities
> 
> 2.1. Route Filtering of External Routing Protocols
> 
>    Capability.
>    The device MUST provide a means to filter routing updates for all
> 
> Minor formatting issue...looks better if you do something like:
> 
> "   Capability
> 
>       The device provides..."
> 
> Note the spacing and indentatoin.   xml2rfc handles this for you.
> Same issue with all subsections.
> 
> 
> gmj> s/MUST provide/provides/ Change MUSTs to simple assertions.
> gmj> Same issue throughout the document.

According to the conclusion in last meeting, I will delete all the MUSTs,
SHOULDs and so on.


> 
>    - Routers MUST allow operators to configure route filters which
>    restrict which routes are accepted from other peer routers. Route
>    filters MUST be capable of being individually configured on a per-
>    neighbor basis.
> 
> gmj> remove the MUSTs.  Break this into two items.   Possibly break
> gmj> each one of these items out into it's own capability 
> (e.g. 1. why 
> gmj> do you want to be able to resrict route updates 2. why is it 
> gmj> important to do it on a per-neighbor basis ?
> 
>    - Routers MUST allow operators to configure route filters which
>    restrict which routes are sent to other peer routers. Route filters
>    MUST be capable of being individually configured on a per-neighbor
>    basis.
> 
>    - Routers SHOULD allow operators to configure whether 
> Outbound Route
>    Filters [ORF] are accepted from other peer routers. This SHOULD be
>    configurable on a per-neighbor basis.
> 
> 
> 
> 
> Zhao                  Expires December 29, 2006               [Page 5]
> > 
> Internet-Draft   Control Plane Security Capabilities         June 2006
> 
> 
>    - Routers SHOULD allow operators to configure which (if 
> any) Outbound
>    Route Filters [ORF] are sent to other peer routers. This SHOULD be
>    configurable on a per-neighbor basis.
> 
>    In general route filters determine whether a route is accepted from
>    or sent to a neighboring router. Filters MAY be based upon any
>    combination of route attributes, such as:
> 
>       - Specific route prefixes
> 
>       This may include a list of specific prefixes to be accepted or
>       rejected. This may alternately include a list of prefixes, such
>       that more specific (longer) prefixes which are included in the
>       more inclusive (shorter) prefix are accepted, rejected, or
>       summarized into the shorter prefix.
> 
>       - Maximum length of route prefix
> 
>       - Maximum number of routes to be accepted from a particular peer
>       router
> 
>       If too many routes are received, then the router may reset the
>       BGP session, or may reject excess routes. In either case the
>       failure event should be logged.
> 
> gmj> These need to be split out.  Resetting an overactive 
> session may be 
> gmj> good (why ?).  Logging falures may be good (why ?).  They are 
> gmj> separate capabilities.

I am planning to split them out.

> 
>       - Restrictions on the AS_PATH
> 
>       Restrictions on the contents of the AS PATH are frequently used:
>       for example if you get a prefix from AS X, then you 
> might want to
>       make sure that X is in the AS PATH.
> 
> 
>       - Restrictions on BGP Community and Extended Community
> 
> 
> 
>    Route redistribution is used to exchange routing 
> information between
>    different protocols. Although route redistribution bridges between
>    different route domains and improves the flexibility of routing
>    system, it may lead to looping or black hole as well.
> 
> gmj> this (preventing loops) looks like the supported 
> practice for the 
> gmj> capability defined below.

I have added a new section to disscuss route redistribution.

According to route authentication I have adjusted the descriptions and
some capabilities, such as more strong algorithms, will be deleted ,
because they are not implemented in current devices.


> 2.3. Ability to Filter Routing Update by TTL
> 
>    Capability
>    The device should provide a means to filter route packets based on
> 
> s/should provide/provides/
> 
>    the value of the TTL field in the IPv4 header or the 
> Hop-Limit field
>    in the IPv6 header.
> 
> gmj> The preceeding looks like a capability.   The following 
> looks like
> gmj> a supported practice.
> gmj>
> gmj> Also, you should cite 3682 here.   You list it in your 
> references.
> gmj> As a general rule, if you have something listed in your 
> references 
> gmj> it should be cited in the body of the document (I think the RFC 
> gmj> editor may enforce this before publication).
> gmj>
> gmj> This whole section looks like good material...it just 
> needs to be 
> gmj> re-arranged a bit.
> 

OK, I will cite [GTSM]

Sorry for the delay to reply, because I was on sick leave.

Zhao Ye