Re: Begin last call on draft-ietf-opsec-infrastructtre-security-01

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 11 Jun 2007, patrick cain wrote:
> This is a call to begin a WG last call on the above mentioned draft.
> The last call will end in two weeks, around June 26, 2007.
>
> The only comments I have seen in the past were on section 6, and I 
> haven't seen anyone offer replacement working for the contentious 
> sentence. I have seen a couple people complain and a larger set of 
> people state that they actually do it, which leads me to believe 
> that we have reasonable consensus from the operators on the issue.

I do not believe it is appropriate to make those who bring up the 
issue incumbent on providing new text.

As such I do not think this document is ready for publication as a 
BCP.

However, in the spirit of making explicit suggestions how to improve 
the document, here are some suggestions for Section 6:

 - the first two sentences of Section 6 are incorrect.  It uses the
   term 'devices' and 'making them unreachable', yet multiple
   techniques listed in the following subsections don't do that.
   E.g., section 6.1 suggests using unnumbered point-to-point links,
   yet the routers are still reachable through their loopback
   addresses.  The third sentence also seems to weakly imply that
   infrastructure hiding would make the _whole_ infrastructure
   unreachable.  Serious rewording is needed here.

 - Section title of 6.1 is too generic: "Use Less IP" is not very
   helpful.  Maybe: "Use Unnumbered Point-to-Point Links".

 - Section title of 6.2 seems too generic: "MPLS Techniques" as the
   only thing listed here seems to be about end-to-end MPLS LSPs which
   do not expose MPLS-only hops.  Make that more explicit and reword
   the title, e.g.: "Expose IP Infrastructure Only At the Edges of
   MPLS Cloud".

 - Section title of 6.3 is too generic: "IGP Configuration" is not
   very helpful.  The point seems to be that using a non-IP protocol
   (i.e., IS-IS), most links do not need to have IP addresses and as
   such those links' IP addresses don't need to be exposed on the
   outside.  On the other hand, I suspect those devices still need to
   have at least one public IP address as a loopback address.

   Maybe better title: "Use IS-IS so Links Don't Need IP Addresses".

   Rephrase the first sentence as follows the unstated implication
   about non-IP link numbering:

   Where unnumbered links cannot be used, one possibility is to use a
   non-IP routing protocol (i.e., IS-IS) and use only non-IP addresses
   (e.g. CLNS) on those links.  This approach reduces the number of IP
   addresses that comprise (and therefore, expose) the core by the
   number of core links; loopback IP addresses are typically still
   necessary.

 - I'd argue Section 6.4.1 is basically useless as a protection
   mechanism as anyone who uses a default route or statically routes
   to you gets around that "protection".  This shortcoming should be
   more explicit or the section should be removed.

 - Section 6.4.2 on RFC1912 use is simply unacceptable for a BCP
   document.  It seems to be phrased so that it could be read that the
   whole core has RFC1912 addresses.  This should be removed or
   rephrased.  An acceptable rephrasing would be emphasizing this
   technique only *in addition* to public addresses.  For example, it
   would be appropriate to set up iBGP peering sessions using private
   addresses, but still make sure that traceroute and other tools
   continue to function by having a public IP address.

 - I'd argue that Section 6.5 does not provide any useful guidance
   worth of a BCP and should probably be removed.  (It could be OK for
   an Informational document though.)

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings