RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 835

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-02-15
Verifier Name: Merike Kaeo
Date Verified: 2007-02-18

Section 2.2.3 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".)



Notes:

wrong acronym expansion

Status: Held for Document Update (1)

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 843

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-01-22
Held for Document Update by: Ron Bonica

 

Studying the recently published RFC 4788 (EVRCB)
authored by you, and comparing it with similar recent
publications,  I'm surprised to find a quite unusual
syntax used in the 'a=fmtp' SDP lines there.

Usually, media type parameters included into 'a=fmtp' SDP lines
are separated by semicolons as in the MIME type declaration.

The most recent RFC formally specifying this behaviour was
RFC 4749, Section 6.2 of which says:

   o  Any remaining parameters go in the SDP "a=fmtp" attribute by
      copying them directly from the media type string as a semicolon
      separated list of parameter=value pairs.

As another example, RFC 4396, in section 9.1, explicitely specifies
the syntax as:
        a=fmtp:<dynamic payload type>
               <parameter name>=<value>[,<value>]
               [; <parameter name>=<value>]

Note: This is *not* ABNF, as can be ssen from the context there.
      Matching RFC-4234 ABNF should have been stated there as:
        a=fmtp:<dynamic-payload-type>
               <parameter-name> "=" <value> *("," <value>)
               *(";" <parameter-name> "=" <value> *("," <value>))

This was common practice over many years.

Section 6.7 of RFC 4788 deviates from this practice, omitting
the semicolon in the examples.  From the prose description,
it is not quite clear whether the phrase,
    "... copying it directly from the MIME media type string"
was meant to comprise the separating semicolons often considered
part of MIME type parameters as well, or not.
Unfortunately, no precise formal description (ABNF) is given.
The examples given all omit the usual semicolons, e.g.:

     a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
                            ^         ^         ^

Has this omission been done intentionally?

If yes, what have been the reasons to do so?
  I fear that the unusual definition might cause
  interoperability problems; at least it makes the use
  of uniform parsing of 'a=fmtp' SDP lines impossible.

It should say:

[not submitted]

Notes:

from pending

Status: Rejected (1)

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 833

Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-02-15
Rejected by: Merike Kaeo

 

(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.

It should say:

[not submitted]

Notes:

Merike Kaeo wrote:
"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."

from pending

Report New Errata



Search RFCs
Advanced Search
×