Subject: Re: RFC 4778 errata

From: Merike Kaeo <[email-masked]>
Date: Sun, 18 Feb 2007 13:23:35 -0800

Hello.

Thanks for the thorough read and comments.

I think that the first flaw is quite serious and definitely needs the  
errata note.
The spelling/typos I'm not so sure make that much of a difference for  
anyone
reading them and would prefer that they not be used.  How strongly do  
you
feel that they should be included?

- merike

On Feb 15, 2007, at 3:13 PM, Alfred HÎnes wrote:

> Hello,
> after studying the recently published RFC 4778 (OPSEC Practices)
> authored by you, I would like to submit a few comments, pointing
> out some issues I found with the RFC text, and supplying material
> for an appropriate RFC Errata Note.
>
> I first explain the single more serious flaw I found; the items
> covering minor flaws (typos and grammar issues) are presented
> subsequently in RFC textual order.
>
> I use change bars ('|' in column 1) and occasionally
> up/down pointing marker lines ('^^^'/'vvv') to emphasize
> the location of textual issues and/or proposed corrections.
> Modified text has been re-adjusted to match RFC formatting
> rules, where appropriate.
>
>
> (1)  Section 2.2.3 -- wrong acronym expansion
>
> The second paragraph of Section 2.2.4, on page 15, says:
>
>    SSH may not be supported on legacy equipment.  In some cases,
>    changing the host name of a device requires an SSH rekey event  
> since
> |  the key is based on some combination of host name, Message
> |  Authentication Code (MAC) address, and time.  [...]
>
> It should say:
>
>    SSH may not be supported on legacy equipment.  In some cases,
>    changing the host name of a device requires an SSH rekey event  
> since
> |  the key is based on some combination of host name, Media Access
> |  Control (MAC) address, and time.  [...]
>
> (Or perhaps simply, and more generally, use "link layer address"
>  in place of "Media Access Control (MAC) address".)
>
>
> (2)  Section 2.1.2 -- typo
>
> The final paragraph of Section 2.1.2, on page 9, says:
>
> |  How ISPs manage these logins vary greatly, although many of the
>    larger ISPs employ some sort of AAA mechanism to help automate
>    privilege-level authorization and utilize the automation to bypass
>    the need for a second authentication step.  [...]
>
> It should say:
>                                    vvv
> |  How ISPs manage these logins varies greatly, although many of the
>    larger ISPs employ some sort of AAA mechanism to help automate
>    privilege-level authorization and utilize the automation to bypass
>    the need for a second authentication step.  [...]
>
>
> (3)  Section 2.2 -- typo
>
> The first paragraph of Section 2.2, on page 10, says:
>
>                          [...].  Note that while many of the security
>    concerns and practices are the same for OOB management and in-band
>    management, most ISPs prefer an OOB management system, since access
> |  to the devices that make up this management network are more
>    vigilantly protected and considered to be less susceptible to
>    malicious activity.
>
> It should say:
>
>                          [...].  Note that while many of the security
>    concerns and practices are the same for OOB management and in-band
>    management, most ISPs prefer an OOB management system, since access
> |  to the devices that make up this management network is more
>    vigilantly protected and considered to be less susceptible to
>    malicious activity.
>
>
> (4)  Section 2.2.2 -- typo, and mis-wording
>
> (4a)
> Within Section 2.2.2, the 4th paragraph on page 13 says:
>
>                                              [...].  Most large ISPs
>    have multiple SNMP systems accessing their routers so it takes more
> |  then one maintenance period to get all the strings fixed in all the
>    right systems.  SNMP RW is not used and is disabled by  
> configuration.
>      ^
> It should say:
>
>                                              [...].  Most large ISPs
>    have multiple SNMP systems accessing their routers so it takes more
> |  than one maintenance period to get all the strings fixed in all the
>    right systems.  SNMP RW is not used and is disabled by  
> configuration.
>
> (4b)
> The next (5th) paragraph on page 13 says:
>
>    Access control is strictly enforced for infrastructure devices by
> |  using stringent filtering rules.  A limited set of IP addresses are
>    allowed to initiate connections to the infrastructure devices  
> and are
> |  specific to the services to which they are to limited (i.e., SSH  
> and
>    SNMP).
>                                              ^^^^
> I suspect that it was intended to say:
>
>    Access control is strictly enforced for infrastructure devices by
> |  using stringent filtering rules.  A limited set of IP addresses is
> |  allowed to initiate connections to the infrastructure devices, and
> |  these addresses are specifically limited to the respective services
> |  (i.e., SSH and SNMP).
>
> (or use similar wording).
>
>
> (5)  Section 2.2.3 -- word twister
>
> In Section 2.2.3, on page 15, the 3rd bullet says:
>
>    o  Data Origin Authentication - Management traffic is strictly
>       filtered to allow only specific IP addresses to have access  
> to the
> |     infrastructure devices.  This does not alleviate risk the from
>       spoofed traffic, although when combined with edge filtering  
> using
>       BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
>       Section 2.5), then the risk of spoofing is mitigated, barring a
>       compromised internal system.  [...]
>
> It should say:
>
>    o  Data Origin Authentication - Management traffic is strictly
>       filtered to allow only specific IP addresses to have access  
> to the
> |     infrastructure devices.  This does not alleviate the risk from
>       spoofed traffic, although when combined with edge filtering  
> using
>       BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
>       Section 2.5), then the risk of spoofing is mitigated, barring a
>       compromised internal system.  [...]
>
>
> (6)  Section 2.3 -- typo
>
> The 1st sentence of Section 2.3, on top of page 16, says:
>
>    This section refers to how traffic is handled that traverses the
> |  network infrastructure device.  [...]
>
> It should say:
>
>    This section refers to how traffic is handled that traverses the
> |  network infrastructure devices.  [...]
>                                 ^
>
> (7)  Section 2.3.4 -- typo
>
> The last paragraph of Section 2.3.4, on page 18, says:
>
>                                         [...].  One such example is at
> |  edge boxes, where up to 1000 T1s connecting into a router with an
>    OC-12 (Optical Carrier) uplink.  [...]
>                                            ^^^
> It should say:
>
>                                         [...].  One such example is at
> |  edge boxes, where up to 1000 T1s connect into a router with an  
> OC-12
>    (Optical Carrier) uplink.  [...]
>
>
> (8)  Section 2.5.2 -- typos
>
> (8a)
> The first paragraph of Section 2.5.2, on page 24, says:
>
>    Images and configurations are stored on specific hosts that have
>    limited access.  All access and activity relating to these hosts  
> are
> |  authenticated and logged via AAA services.  When uploaded/ 
> downloading
>    any system software or configuration files, either TFTP, FTP, or  
> SCP
>    can be used.  Where possible, SCP is used to secure the data  
> transfer
>    and FTP is generally never used.  All SCP access is username/ 
> password
>    authenticated but since this requires an interactive shell, most  
> ISPs
>    will use shared key authentication to avoid the interactive shell.
>    While TFTP access does not have any security measures, it is still
>    widely used, especially in OOB management scenarios.  Some ISPs
> |  implement IP-based restriction on the TFTP server, while some  
> custom
>    written TFTP servers will support MAC-based authentication.  The
>    MAC-based authentication is more common when using TFTP to  
> bootstrap
>    routers remotely.
>
> It should say:
>
>    Images and configurations are stored on specific hosts that have
>    limited access.  All access and activity relating to these hosts  
> are
> |  authenticated and logged via AAA services.  When uploading /
>    downloading any system software or configuration files, either  
> TFTP,
>    FTP, or SCP can be used.  Where possible, SCP is used to secure the
>    data transfer and FTP is generally never used.  All SCP access is
>    username/password authenticated but since this requires an
>    interactive shell, most ISPs will use shared key authentication to
>    avoid the interactive shell.  While TFTP access does not have any
>    security measures, it is still widely used, especially in OOB
> |  management scenarios.  Some ISPs implement IP-based restrictions on
>    the TFTP server, while some custom written TFTP servers will  
> support
>    MAC-based authentication.  The MAC-based authentication is more
>    common when using TFTP to bootstrap routers remotely.
>
> (8b)
> The second paragraph of Section 2.5.2, on page 24, says:
>
>    [...]                      v     vv
> |  In at least one environment these, tools are Kerberized to take
>    advantage of automated authentication (not confidentiality).
>    'Rancid' is one popular publicly available tool for detecting
>    configuration and system changes.
>
> It should say:
>
>    [...]                      vv     v
> |  In at least one environment, these tools are Kerberized to take
>    advantage of automated authentication (not confidentiality).
>    'Rancid' is one popular publicly available tool for detecting
>    configuration and system changes.
>
>
> (9)  Appendix A.2 -- typo
>
> The second bullet in Appendix A.2, on page 34, says:
>                              vvvvvvvvvv
> |  o  IP Source Route Option can allows attackers to establish stealth
>       TCP connections.
>
> It should say:
>
> |  o  IP Source Route Option can allow attackers to establish stealth
>       TCP connections.
>
>
> Please comment.
>
> I suggest that at least item (1) above be addressed by an
> RFC Errata Note, and I leave it to your decision whether to
> also include the corrections to the other flaws.
>
> Preferrably, you should submit an Author's Errata Note to the
> RFC Editor's RFC Errata web pages, making freely use of the
> material supplied above.  But if you like, I can formally
> submit an Errata Note on my own, with your consent.
>
> Best regards,
>   Alfred HÎnes.
>
> -- 
>
> +------------------------ 
> +--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.- 
> Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax:  
> -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR- 
> Sys.de                     |
> +------------------------ 
> +--------------------------------------------+
>

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 16 Feb 2007 00:13:25 +0100 (MEZ)

Hello,

   SSH may not be supported on legacy equipment.  In some cases,
   changing the host name of a device requires an SSH rekey event since
|  the key is based on some combination of host name, Message
|  Authentication Code (MAC) address, and time.  [...]

It should say:

   SSH may not be supported on legacy equipment.  In some cases,
   changing the host name of a device requires an SSH rekey event since
|  the key is based on some combination of host name, Media Access
|  Control (MAC) address, and time.  [...]

It should say:
                                   vvv

(3)  Section 2.2 -- typo

It should say:

(4a)

                                             [...].  Most large ISPs
   have multiple SNMP systems accessing their routers so it takes more
|  then one maintenance period to get all the strings fixed in all the
   right systems.  SNMP RW is not used and is disabled by configuration.
     ^
It should say:

                                             [...].  Most large ISPs
   have multiple SNMP systems accessing their routers so it takes more
|  than one maintenance period to get all the strings fixed in all the
   right systems.  SNMP RW is not used and is disabled by configuration.

(4b)

   Access control is strictly enforced for infrastructure devices by
|  using stringent filtering rules.  A limited set of IP addresses are
   allowed to initiate connections to the infrastructure devices and are
|  specific to the services to which they are to limited (i.e., SSH and
   SNMP).
                                             ^^^^
I suspect that it was intended to say:

   o  Data Origin Authentication - Management traffic is strictly
      filtered to allow only specific IP addresses to have access to the
|     infrastructure devices.  This does not alleviate risk the from
      spoofed traffic, although when combined with edge filtering using
      BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
      Section 2.5), then the risk of spoofing is mitigated, barring a
      compromised internal system.  [...]

It should say:

   o  Data Origin Authentication - Management traffic is strictly
      filtered to allow only specific IP addresses to have access to the
|     infrastructure devices.  This does not alleviate the risk from
      spoofed traffic, although when combined with edge filtering using
      BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
      Section 2.5), then the risk of spoofing is mitigated, barring a
      compromised internal system.  [...]

(6)  Section 2.3 -- typo

It should say:

                                        [...].  One such example is at
|  edge boxes, where up to 1000 T1s connect into a router with an OC-12
   (Optical Carrier) uplink.  [...]

(8a)

   Images and configurations are stored on specific hosts that have
   limited access.  All access and activity relating to these hosts are
|  authenticated and logged via AAA services.  When uploaded/downloading
   any system software or configuration files, either TFTP, FTP, or SCP
   can be used.  Where possible, SCP is used to secure the data transfer
   and FTP is generally never used.  All SCP access is username/password
   authenticated but since this requires an interactive shell, most ISPs
   will use shared key authentication to avoid the interactive shell.
   While TFTP access does not have any security measures, it is still
   widely used, especially in OOB management scenarios.  Some ISPs
|  implement IP-based restriction on the TFTP server, while some custom
   written TFTP servers will support MAC-based authentication.  The
   MAC-based authentication is more common when using TFTP to bootstrap
   routers remotely.

It should say:

   Images and configurations are stored on specific hosts that have
   limited access.  All access and activity relating to these hosts are
|  authenticated and logged via AAA services.  When uploading /
   downloading any system software or configuration files, either TFTP,
   FTP, or SCP can be used.  Where possible, SCP is used to secure the
   data transfer and FTP is generally never used.  All SCP access is
   username/password authenticated but since this requires an
   interactive shell, most ISPs will use shared key authentication to
   avoid the interactive shell.  While TFTP access does not have any
   security measures, it is still widely used, especially in OOB
|  management scenarios.  Some ISPs implement IP-based restrictions on
   the TFTP server, while some custom written TFTP servers will support
   MAC-based authentication.  The MAC-based authentication is more
   common when using TFTP to bootstrap routers remotely.

(8b)

   [...]                      v     vv

It should say:

   [...]                      vv     v

(9)  Appendix A.2 -- typo

It should say:

Please comment.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+