[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Lars-Johan Liman <liman@sunet.se>
Cc: dnsop@cafax.se
From: Randy Bush <randy@psg.com>
Date: Wed, 01 Dec 1999 07:49:23 -0800
Sender: owner-dnsop@cafax.se
Subject: Re: Last WG call for draft-ietf-dnsop-root-opreq-02.txt.

> draft-ietf-dnsop-root-opreq-02.txt

steve bellovin had some comments which have caused an -03 version which i
will be sending in later today.  the changes are minor.

***************
*** 233,242 ****
               as http, telnet, rlogin, ftp, etc.  The only login accounts
               permitted should be for the server administrator(s).
               "Root" or "privileged user" access MUST NOT be permitted
!              except through an intermediate user account.  If remote
!              access is required for administration and maintenance then
!              the login MUST be protected by a secure means that is
!              strongly authenticated and encrypted.
  
         3.2.2 Root name servers SHOULD NOT trust other hosts, except
               secondary servers trusting the primary server, for matters
--- 233,248 ----
               as http, telnet, rlogin, ftp, etc.  The only login accounts
               permitted should be for the server administrator(s).
               "Root" or "privileged user" access MUST NOT be permitted
!              except through an intermediate user account.
! 
!              Servers MUST have a secure mechanism for remote
!              administrative access and maintenance.  Failures happen;
!              given the 24x7 support requirement (per 4.5), there will be
!              times when something breaks badly enough that senior
!              wizards will have to connect remotely.  Remote logins login
!              MUST be protected by a secure means that is strongly
!              authenticated and encrypted, and sites from which remote
!              login is allowed MUST be protected and hardened.
  
         3.2.2 Root name servers SHOULD NOT trust other hosts, except
               secondary servers trusting the primary server, for matters
***************
*** 248,254 ****
         3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
               also home crackable hosts.  I.e. the LAN segments should be
               switched or routed so there is no possibility of
!              masquerading.
  
         3.2.4 The LAN segment(s) on which a root server is homed SHOULD
               be separately firewalled or packet filtered to discourage
--- 254,263 ----
         3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
               also home crackable hosts.  I.e. the LAN segments should be
               switched or routed so there is no possibility of
!              masquerading.  Some LAN switches aren't suitable for
!              security purposes, there have been published attacks on
!              their filtering.  While these can often be prevented by
!              careful configuration, extreme prudence is recommended.
  
         3.2.4 The LAN segment(s) on which a root server is homed SHOULD
               be separately firewalled or packet filtered to discourage
***************
*** 268,289 ****
               attempts, etc.  Servers SHOULD log in GMT to facilitate log
               comparison.
  
         3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
               protected similarly to the root servers themselves.
  
         3.2.8 The server SHOULD be protected from attacks based on source
!              routing.
  
         3.2.9 The network on which the server is homed SHOULD have in-
               addr.arpa service.
  
     3.3 Protocol authentication and security are required to ensure that
         data presented by the root servers are those created by those
         authorized to maintain the root zone data.
--- 277,299 ----
               attempts, etc.  Servers SHOULD log in GMT to facilitate log
               comparison.
  
         3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
               protected similarly to the root servers themselves.
  
         3.2.8 The server SHOULD be protected from attacks based on source
!              routing.  The server MUST NOT rely on address- or name-
!              based authentication.
  
         3.2.9 The network on which the server is homed SHOULD have in-
               addr.arpa service.
  
     3.3 Protocol authentication and security are required to ensure that
         data presented by the root servers are those created by those
         authorized to maintain the root zone data.
***************
*** 300,306 ****
               when supported.
  
         3.3.3 Transfer of the root zone between root servers MUST be
!              authenticated and be as secure as reasonably possible.
               Servers MUST use DNSSEC to authenticate root zones received
               from other servers.  It is understood that DNSSEC is not
               yet deployable on some common platforms, but will be
--- 310,317 ----
               when supported.
  
         3.3.3 Transfer of the root zone between root servers MUST be
!              authenticated and be as secure as reasonably possible.  Out
!              of band security validation of updates MUST be supported.
               Servers MUST use DNSSEC to authenticate root zones received
               from other servers.  It is understood that DNSSEC is not
               yet deployable on some common platforms, but will be
***************
*** 422,428 ****
     Singel 258
     NL-1016-AB Amsterdam
     Netherlands
!    EMail: dfk@ripe.net
  
     Mark Kosters
     Network Solutions
--- 432,438 ----
     Singel 258
     NL-1016-AB Amsterdam
     Netherlands
!    EMail: daniel.karrenberg@ripe.net
  
     Mark Kosters
     Network Solutions
***************

Home | Date list | Subject list