catchup

[George Jones <gmj@pobox.com>]

Catching up on things I've missed:

    * /To/: Alex Zinin <zinin at psg.com <mailto:zinin@DOMAIN.HIDDEN>>,
      routing-discussion at ietf.org
      <mailto:routing-discussion@DOMAIN.HIDDEN>
    * /Subject/: Re: Last Call: draft-jones-opsec "Operational Security
      Requirements for IP Network Infrastructure"
    * /From/: Ross Callon <rcallon at juniper.net
      <mailto:rcallon@DOMAIN.HIDDEN>>
    * /Date/: Thu, 05 Feb 2004 11:50:27 -0500
    * /Cc/: iesg at ietf.org <mailto:iesg@DOMAIN.HIDDEN>

------------------------------------------------------------------------
rc> I think that this is a very useful document, and is quite well done. The
rc> topic is also quite urgent. I therefore encourage publication.
rc>
rc> My comments are very minor editorial comments, and are intended
rc> only to be helpful (if any of these are controversial then "never mind").
rc>
rc>
rc> Regarding the title: it is very clearly stated in the scope section that
rc> this
rc> document covers routers and switches. My general interpretation of the
rc> phrase "IP Network Infrastructure" tends to include servers as well. It
rc> therefore seems reasonable to change the title to "Operational Security
rc> Requirements for IP Routers and Switches". (although I wouldn't change
rc> the title if this requires any major trouble -- the stated scope is very
rc> clear,
rc> and some of these requirements might carry over to other devices).

The scope is actually "things that transit packets in very large networks".
I think "infrastructre" is more accurate/less limiting than "routers and switches".

rc> Section 1.4, second bullet item: In principle a packet could be delivered
rc> to more than one place. Thus I would be inclined to reword this bullet as:
rc>
rc>         o traffic goes where its supposed to go, and only where its supposed
                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
rc>            to go (availability, confidentiality)
               ^^^^^

Changed.

rc>
rc>
rc> Section 1.5, In interpret the phrase "end user" to be a person sitting at
rc> home on the other end of a dial-up or DSL connection, or perhaps a
rc> company. Thus I think that "end user" could be changed to "network
rc> operator" so that this section reads:
rc>
rc>         There are two intended audiences: the network operator who selects,
rc>         purchases, and operates IP network equipment, and the vendors who
rc>         create them.

Changed.

rc>
rc> Page 10, definition of "Single-Homed Network". Does this include a network
rc> which has two physical links to the same service provider? Does this depend
rc> upon whether this results in the network having a single address prefix that
rc> needs to be advertised? It seems to me that the issue is primarily
rc> related to
rc> addressing and routing, and the related checking of source addresses. Thus
rc> the definition looks good, but a little clarification might not hurt.
rc> This is a
rc> difficult area to get precisely the right wording, but how about a comment
rc> along the line of:
rc>
rc>         Note: A single homed network may have more than one physical links
rc>         to the same service provider, so long as the connection can be
rc> treated
rc>         as one logical connection for the purpose of inter-domain
rc> routing and
rc>         addressing.

I've since been over this several times with Pekka Savola.
I think this in much better shape now.   See

  http://www.port111.com/opsec/draft-jones-opsec-04.txt

rc>
rc>
rc> Page 27/28, section 2.5.6, discussion of anti-spoofing filters. Current text
rc> for the example says:
rc>
rc>         Examples.
rc>         This requirement could be satisfied in several ways. It could be
rc>         satisfied by the provision of a single command that automatically
rc>         generates and applies filters to an interface that implements
rc>         anti-spoofing. It could be satisfied by the provision of a
rc>         command that causes the return path for packets received to be
rc>         checked against the current routing tables and dropped if they
rc>         would not be forwarded back through the interface on which they
rc>         were received.
rc>
rc> This is perhaps a nit. In the single-homed case, the text is correct as
rc> it currently stands. If we wanted this to extend to spoof checking in
rc> other cases, then you want a slightly less rigid check, in that there
rc> might be multiple paths, and you want to accept the packet if /any
rc> /path exists back to the source over the interface, not just the paths
rc> that you happen to have chosen. Thus we could generalize this as
rc> follows:
rc>
rc>         Examples.
rc>         This requirement could be satisfied in several ways. It could be
rc>         satisfied by the provision of a single command that automatically
rc>         generates and applies filters to an interface that implements
rc>         anti-spoofing. It could be satisfied by the provision of a
rc>         command that causes the return path for packets received to be
rc>         checked against the current routing tables and dropped if they
rc>         could not be forwarded back through the interface on which they
rc>         were received (ie, if no path to the source exists over the
rc> interface).

Ditto.

Thanks,
---George