[no subject]

[George Jones <gmj@pobox.com>]

> Date and Time: 2004-01-22, 11:12:17
> Version: 03
> Commented by: Hardie, Ted
> State before Comment: 0
> State after Comment: 0

> Comment: I don't support this going for BCP.  There are a number of
> cases in the document where there are value judgments

Quite probably.   I attempted to keep it neutral and justify
requirements,  but I probably failed in some places.

> about the
> trade-offs between user needs and operator needs,

In this case the perspective taken is "user == operator".

The document is trying to answer the question "what features
do operators need to be able to deploy gear securely into their
networks".

> and I feel that
> the documents justification of them simply does not past muster for
> best current practice.  One example:

>
> 2.8.3 Ability to Filter on Protocol Header Fields
>
>   Requirement. The filtering mechanism MUST support filtering based on
>       the value(s) of any portion of the protocol headers for IP,
>       ICMP,
>       UDP and TCP. It SHOULD support filtering of of all other
>       protocols
>       supported at layer 3 and 4.  It MAY support support filtering
>       based on the headers of higher level protocols.  It SHOULD be
>       possible to specify fields by name (e.g. "protocol = ICMP")
>       rather
>       than bit-offset/length/numeric value (e.g. 72:8 = 1).
>
>   Justification. Being able to filter on portions of the header is
>       necessary to allow implementation of policy, secure operations,
>       and support incident response.
>
...

> A network could well make a choice that the ability to filter on
> layer 4 protocol information (especially headers) opened the network
> to abuse by operators, local law enforcement, or black hats;

The requirement is not saying that filtering has to be/not be done,
simply that the capability has to be there.

There are assumptions that

  - the system is operated in accordance with local policy
  - the policies are in accord with local law
  - operating within law and policy is in the users best interest
  - the system is being managed securely by authorized personnel
    (using features required by this doc) in accordance with local
    policy and law.

If these assumptions fail, all bets are off.  Do you think they need
to be made explicit ?

> deciding to limit that capability could be a rational for some
> networks, just as this decision might be rational for others.  As
> written, the trade-offs aren't discussed.

Yes.  That's why it says "support" not "perform".   This is about
features needed to support policies, possibly a wide range of
policies, not about the policies themselves.

> I also find the document's view of "single homed" to be inadequate
> (since it doesn't distinguish between the cases where a network may
> have multiple exits to the same AS and a single exit, and since it
> doesn't acknowledge that routing isn't necessarily symmetric past
> the first hop in either case).

What this is trying to say is that for the simple case, one way in,
one way out,  there should be a fairly painless way to comply with
RFC2827.   I used to do security for ~400 routers+switches in ~20
web-hosting data centers.   This could have cut out a lot of crap.

I've updated the definition by removing "(logical)" from before
"upstream connection" and referenced the Savola/Baker draft for info
on the multi-homing case.

04>   Single-Homed Network.
04>
04>      A "single-homed network" is defined as one for which
04>      *  There is only one upstream connection
04>      *  Routing is symmetric
04>
04>      See [I-D.savola-bcp38-multihoming-update] for a discussion of
04>      related issues and mechanisms for multihomed networks.


> I'm also disturbed by the "Warnings" style of operational
> specification.

The warnings are there, where it made sense, to give heads up about
potential problems (e.g. performance impact) or other issues connected
with the feature.

> That may be too deeply ingrained in the document to
> change at this point, but it really sounds much more prescriptive
> than this document ought to be.  There are balance points in all of
> this among competing needs, and this document's flat statements can
> really elide how circumstances can cause other choices to be valid.

The profiles mechanism, which is prominent throughout the document
from abstract to appendix was an explicit attempt to say "your mileage
may vary".  It is explicitly stated that "The profiles in this document
should be reviewed to determine if they are appropriate to the local
environment." and that one of the intended uses is to aid in Composing
profiles from different subsets to describe the needs of different
devices, organizations, and operating environments."

Perhaps this is not well reflected in the individual requirements, but
I don't see how I could have been more explicit about the need to
tailor for local needs in the intro:

(quotes are from the working "-04", but have not changed from -03)

04> Abstract
04>
04>   A framework is defined for specifying "profiles", which are
04>   collections of requirements applicable to certain network topology
04>   contexts (all, core-only, edge-only...).
04>
04>1.3 Scope
04>
04>   ....
04>
04>   In order to assist in classification, the Appendix A defines
04>   several requirement "profiles" for different types of devices.
04>   Profiles are concise lists of requirements that apply to certain
04>   classes of devices.  The profiles in this document should be
04>   reviewed to determine if they are appropriate to the local
04>   environment.
04>
04>1.7 Intended Use
04>
04>   It is anticipated that this document will be used for the following
04>   purposes:
04>
04>   ...
04>
04>   Composing Profiles. Composing profiles from different subsets to
04>      describe the needs of different devices, organizations, and
04>      operating environments.
04>
04>Appendix A. Requirement Profiles
04>
04>   This Appendix lists different profiles.  A profile is a list of
04>   list of requirements that apply to a particular class of devices.
04>   The minimum requirements profile applies to all devices.
04>
04>A.1 Minimum Requirements Profile
04>
04>...
04>
04>A.2 Layer 3 Network Edge Profile

> (The whole console port discussion being another one where deeply
> held assumptions about the size and placement of gear may hide the
> fact that there are other rational choices for other types of gear
> that still fall under the rubric "IP Network Infrastructure")

This one was changed quite a bit as a result of NANOG discussions.

Thanks,
----George Jones