RFC Errata
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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