Re: [RPSEC] RPsec not meeting in Prague

>Don't forget WG Last Call on draft-ietf-rpsec-bgpsecreq-07 is almost
>up.

I have a few comments that are content or process related.  Comments
on typos I'll send directly to the editor.  Later.

--Sandy

=============================

CONTENT RELATED

1)----------------------------Service Interruption

As you might have guessed by my message last week, I think the following:

   o  In an environment where secured service is in the process of being
      deplyed a mechanism MUST exist to support a transition free of
      service interruption.

is too generally stated.  Curtis's and Doug's responses both
interpreted this not to mean *ANY* service interruption, but instead
to mean a widespread service interruption.  Curtis mentioned flag days
and Doug mentioned global service interruptions.

I don't think it is wise to write a requirement document with "MUST"s
in them that have to be interpreted with a grain of salt. I also don't
think it would take much to capture the thought that is intended:

   o  In an environment where secured service is in the process of being
      deployed a mechanism MUST exist to support a transition free of
      coordinated, widespread service interruption.

OK?

2)----------------------------Multi-homed PI space

In Section 7, it discusses the fact that "addresses allocated to one
organization may be, and are quite commonly, advertised by ASes
belonging to other organizations."  I can't read the language as
covering the case of PI addresses originated by multiple upstream
AS's.  I think that's a common case, so I wonder why it isn't there.

Of course, the language might be intended to cover that case and I'm
just not reading it right.

If that case is truly missing, I'd say it needs to be added.  It doesn't
change the MUST in the section, but it would reassure PI space holders
(particularly the legacy folk) that their needs are being considered.

=============================

BUREAUCRATIC/PROCESS RELATED

Some of the following I found when I went looking for all the
requirements that are stated in this document.  Not all the sections
listing requirements are entitled as being requirements, so I looked
for RFC 2119 language.

3)----------------------------RFC 2119 boilerplate

The usual boilerplate about RFC2119 wording is missing, even though
we use RFC2119 wording (MUST, SHOULD, etc.).  This gets a id-nits
error.

4)----------------------------Obsolete ref

In Section 1:

   BGP is described in RFC1771 [4], and, more recently, in an updated
   specification, RFC4271 [1], as a path-vector routing protocol.  

RFC1771 is never referred to again in this draft.  There's no reason
to refer to it, it's obsoleted by RFC4271 - I suggest removing the
reference to it entirely (and removing [4] from the reference list).
Like:

   BGP is described in RFC4271 [1], as a path-vector routing protocol.

(This also gets rid of an id-nit warning.)

5)----------------------------Unintended "MUST"

In Section 2  "Underlying Assumptions regarding BGP", there is a
MUST:

                                                     Specifications
      state that the AS routing graph MUST be loop free.  

Certainly I agree that AS routing graphs need to be loop free.  But
did we intend for this to be one of the mandated BGP security
requirements, or was this an unintended capitalization of a normal use
of the word "must"?  There are other places in this section where
"must" is used in the normal everyday way - I think it possible that
this was yet another such normal use that was accidentally 2119'd.

6)----------------------------Is a non-consensus MUST a requirement?

In Section 6

                                                  Special Note: On the
   first two categories below, the community has reached consensus; on
   the latter two (AS_PATH Feasibiliity Check and Update Transit Check),
   the community has not reached consensus.

   o  Authorization of Originating AS: ... MUST ...

   o  Announcing AS Check: ... MUST ...

   o  AS_PATH Feasibility Check: ... MUST ...

   o  Update Transit Check: ... SHOULD ...

What does it mean to list a MUST and a SHOULD requirement but say that
the community did not reach consensus on those items?  Are they
requirements or not?  

I think it would be less confusing to revise the level of requirement
on the last two items ("MAY"?) and leave out the part about not
reached consensus.  Or leave in the not reached consensus part but
un-2119 the language for the last two items.

7)----------------------------Requirement might be impossible

In Section 3.1:

                                                          Two types of
   verification MAY be offered for the NLRI and the AS_PATH in order to
   allow for a selection of optimizations:

   o  Contents of the UPDATE message SHOULD be authenticated in real-
      time as the UPDATE message is processed.

   o  The route information base MAY be authenticated periodically or in
      an event-driven manner by scanning the route-table data and
      verifying the originating AS and the validity of the AS_PATH list.

   All BGP implementations that implement security MUST utilize at least
   one of the above methods for validating routing information.  Real
   time verification is preferred in order to prevent transitive
   failures based on periodic or event-driven scan intervals.  See the
   section on "Local controls ..." below for more discussion.

   It is recognized that achieving all of these goals might prove very
   difficult or even impossible.

OK, so you are allowed to have two types of verification, one a SHOULD
and one a MAY, but you are required to do at least one.  (I think I've
got that right.)

But then what does it mean to say that this requirement might be
impossible?  (Presuming "all of these goals" refers to this section,
not to the whole document!)  Is a recognizably impossible requirement
still a requirement?

8)----------------------------Reference to non-consensus requirement

In Section 9:

   This capability can be afforded by implementation of the
   aforementioned directive that any security system SHOULD provide a
   method to allow the receiver of an UPDATE to verify that the
   originator is actually authorized to originate the update, and that
   the AS's listed in the AS_PATH actually forwarded the update.

If the "aforementioned directive" means that passage I pointed out in
Section 6, the "verify ... that the AS's listed in the AS_PATH
actually forwarded the update" may or may not be a directive at all.
And the part about "verify that the originator is actually authorized
to originate the update" is a MUST in Section 6, not a SHOULD.

9)----------------------------Judging consensus

We say nothing about what would constitute a compliant security
solution.  I do not believe that one security solution could solve all
the requirements here - from local configurability to the requirements
for logging data structures and standard formats.  (Otherwise we
are forcing the solutions to take on the job of the syslog working
group, vendors, etc.)  Can we say that solutions must state which
requirements they meet and which they don't address?  Or do we really
mean that any security solution must solve logging, security
infrastructure protection, etc?

=============================

EDITORIAL

10)---------------------------Originating via data received from peers

In Section 2:

   o  Route Origination: BGP speakers may originate routes based either
      configured internal data or via data received from peers via
      UPDATES.

This is partly a case of the nits I said I'd communicate to the editor
off-list, but even guessing at the nits I'm also pretty unsure what
the intended meaning is -- what does it mean to originate routes "via
data received from peers"?  I would think this was trying to say
something about aggregating received routes, but aggregation is a
topic of a few bullets later.  Since I can't figure out the meaning,
I don't have a suggestion of a revision.

11)---------------------------AS_PATH ... not clearly mandated

In Section 2:

                              While the AS_PATH information is typically
      transitive it is, currently, not clearly mandated and many times
      is modified for various utilitarian reasons.

Another case where I can not make out the meaning.  What is it that is
not clearly mandated?  I can see that the AS_PATH is what is "modified
for various utilitarian reasons", but that would mean that the AS_PATH
is what is mandated, which makes no sense.  And what does it mean to
say that the AS_PATH is transitive?  I'm used to using transitivity as
a property of relations, so a is related to b and b is related to c
means a is related to c.  What does it mean here?

12)---------------------------Information - in or not in the registries

In Section 6:

   All data needed by BGP routers to evaluate the validity of an
   advertisement MUST be made available to the routers in a timeframe
   consistent with the rate at which advertisement characteristics
   change.  Two examples are:

   o  the distribution of information about the AS(es) authorized to
      advertise a given block of IP addresses,

   o  the distribution of information about connectivity between
      autonomous systems and about autonomous system policies

   Note that in today's operational Internet, the first two pieces of

There are only two listed - why say "first two"?

   information, or their analogues, are not a part of the BGP routing
   system per se (e.g., information in Routing or Address registries.)

Sure you mean "not"?

   They are consulted by most operators on an irregular basis and are
   not consulted in real time by the routing system.  

Further evidence that "not" was a mistake - how could they be consulted
if they were not there?

                                                      Policy information
   that is explicitly carried in the routing system is inconsistently
   expressed and consulted in Routing registries by operators.

Does this contradict the "are not part of the ... Routing registries"?

----------------------------

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec