errata logo graphic

Found 12 records.

Status: Verified (2)

RFC4301, "Security Architecture for the Internet Protocol", December 2005

Source of RFC: ipsec (sec)

Errata ID: 2180

Status: Verified
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 4.4.2.2. says:

OPAQUE****        0  prot. "P"    OPAQUE

It should say:

OPAQUE****        0  prot. "P"    discard packet

Notes:

Opaque means protocol must not be available. Therefore this packet does not match and must be discarded.
The same four times more.


Errata ID: 2184

Status: Verified
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section D2 says:

We could define ANY as the complement of OPAQUE,
i.e., it would match all values but only for accessible port fields.

It should say:

We could define ANY as the complement of OPAQUE,
i.e., it would match all values but only for accessible port fields.
But we did not. ANY encompasses OPAQUE.

Notes:

misleading


Status: Held for Document Update (7)

RFC4301, "Security Architecture for the Internet Protocol", December 2005

Source of RFC: ipsec (sec)

Errata ID: 135

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2008-12-04

Appendix A2 says:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE -- included in ICV calculation
         Routing (Type 0)                    [DH98]

       BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
       TRANSIT)
         Hop-by-Hop options                  [DH98]
         Destination options                 [DH98]

       NOT APPLICABLE
         Fragmentation                       [DH98]

It should say:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE
       -- included in ICV calculation
         Routing (Type 0)                       [DH98]

       BIT INDICATES IF OPTION IS MUTABLE
       (CHANGES UNPREDICTABLY DURING TRANSIT)
         Hop-by-Hop options                     [DH98]
         Destination options                    [DH98]

       NOT APPLICABLE
         Fragmentation                          [DH98]

Notes:

Perhaps it should be formatted as shown above to avoid the overlap of the columns.


Errata ID: 717

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11

 

(1)  [typo]

In section 4.1, on page 14, RFC 4301 says:

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

It should say ( s/in used/is used/ ) :

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
|  as that term is used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

(2)  [textual improvement]

In section 4.4.3.2, the last lines on page 45 say:

                                                      [...].  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status, e.g., a list of
 << page break >>
   appropriate OCSP responders or CRL repositories, [...]

This seems to make not much sense. It should perhaps say:

                                                      [...].  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status determination, e.g.,
   a list of appropriate OCSP responders or CRL repositories, [...]

(3)  [typo]

The second paragraph of section 4.4.3.3, on page 46, says:

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
   indicates that child SAs traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. [...]

It should say ( s/SAa/SA/ ) :

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
|  indicates that child SA traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. [...]

(4)  [textual consistency]

Below the table on page 59, section 5.1.2.2 says:

    Notes:

      (1) - (6) See Section 5.1.2.1.

It should say:

    Notes:

|     (1) - (3), (5), (6)  See Section 5.1.2.1.


(5)  [typo]

The second paragraph of App. D.2, on page 89, says:

                                                    [...]. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
   problems arises in that context as well.)
          ^     ^^

There obviously is a singular/plural mismatch.
The text should say:
                                                    [...]. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
|  problem arises in that context as well.)


(6)  Insufficient IPcomp integration

At the end of section 3.1, on page 10, RFC 4301 says:

   IPsec optionally supports negotiation of IP compression [SMPT01],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol
   layers.

It has also been observed that payload compression can help counter
TPA.  Thus, there are at least two reasons for a tight integration
of IPComp with IPsec.
But I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303
as well) for the concrete support of IPComp in ESP / AH IPsec SAs.

IKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shall
that be triggered and work, in an interoperable way, if there are no
architectural provisions for the support of IPComp designed in into
the IPsec databases (SPD, SAD) as described in RFC 4301 ????


(7)  Insufficient integration with QoS (DS)

The steps taken for the integration with Differentiated Services
are half-hearted.  The processing rules specified for the DSCP
field in the IP header[s] remain incomplete as long as there is
no specified interoperable way to use DSCP as an selector as well.

IMHO, the discussion on page 14 of RFC 4301 is misleading because
DS classification and treatment needs to be done independent from
IPsec treatment.
In many scenarios, e.g. on 'hosts' or 'QoS gateways' that must
perform fine-grained traffic classification, DS treatment must
be performed strictly before IPsec treatment in the outbound
case (and after IPsec in the inbound case), to make ULP fields
accessible to the DS classifiers.
IPsec should then be capable of guaranteeing the same security
treatment of all packets of certain traffic class to a given
destination.

I still have problems to imagine how DS integration could be
achieved with the processing model of section 5.1 of RFC 4301.

At the end of section 3.1, on page 10, RFC 4301 says:


(8)  Inconsistent DS Field handling specified in Section 5.1.2.x

The IPv6 related table in section 5.1.2.2 contains the line,

        DS Field         copied from inner hdr (5)    no change (9)

and the subsequent Notes give a lengthy explanation under (9).

Contrary to that, the corresponding table line for IPv4, in section
5.1.2.1 on page 57, is *not* linked to such a note.

I cannot see any reason precluding the application of the arguments
given in Note (9) of section 5.1.2.2 to the IPv4 case as well.

Have I missed any significant point there?


(9)  SA negotiation -- capability mismatch with IKEv2

See section 4.4.1.2, second paragraph.

It should say:

[see above]

Notes:

from pending


Errata ID: 1684

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2009-02-17
Held for Document Update by: Pasi Eronen

Section 4.5.3. says:

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which H1's
   traffic must pass.

It should say:

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which SH1's
   traffic must pass.

Errata ID: 1713

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2009-03-12
Held for Document Update by: Pasi Eronen

Section 12 says:

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

It should say:

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

Notes:

See http://www.iana.org/assignments/smi-numbers


Errata ID: 2179

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 4.4.2.2 says:

list of prot's

It should say:

list of prots

Notes:

This is not genitive. It's plural.


Errata ID: 2181

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk

Section 4.4.3.1. says:

The Key ID field is defined as an OCTET string in IKE.  For this name
type, only exact-match syntax MUST be supported (since there is no
explicit structure for this ID type).  Additional matching functions
MAY be supported for this ID type.

It should say:

The Key ID field is defined as an OCTET string in IKE.  For this name
type, exact-match syntax MUST be supported (since there is no
explicit structure for this ID type).  Additional matching functions
MAY be supported for this ID type.

Notes:

'only A must be supported' is ambigous.
Does it mean 'A must be supportet and anything else must not be supportet', or does it mean 'A must be supportet and anything else may be supportet'. The next sentence clearifies that it is the second interpretation.


Errata ID: 2182

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk

Section 4.4.3.2 says:

This document requires support for two required authentication data
types:

It should say:

This document requires support for two authentication data
types:

Notes:

pleonasm


Status: Rejected (3)

RFC4301, "Security Architecture for the Internet Protocol", December 2005

Source of RFC: ipsec (sec)

Errata ID: 2178

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.1.1. says:

SPD-S, SPD-I, SPD-O
Pages 20,21

It should say:

Needs to be formulated differently.

Notes:

This text needs information which comes later in RFC4301. There must be an explanation of decorrelation (hint on Appendix B).
The part of outbound traffic is confusing. If you have no SPD-S entries, you can handle it the same way as explained for inbound traffic.
--VERIFIER NOTES--
There is no section 4.1.1.


Errata ID: 2183

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 5.1. says:

There is no requirement that an implementation buffer the packet if there is a cache miss.

It should say:

There is no requirement that an implementation buffers the packet if there is a cache miss.

Notes:

typo
--VERIFIER NOTES--
original text was grammatically correct.


Errata ID: 2661

Status: Rejected
Type: Editorial

Reported By: Bob Briscoe
Date Reported: 2010-12-04
Rejected by: Sean Turner
Date Rejected: 2011-03-10

Section header block says:

Obsoletes: 2401

It should say:

Obsoletes: 2401
Updates: 3168

Notes:

RFC 4301 updates RFC 3168 but does not indicate this in its header block.

Specifically, RFC 4301 updates the processing of the ECN field for IPsec tunnel mode that was specified in RFC 3168.
--VERIFIER NOTES--
This action was taken already. The RFC index is already updated and so is the datatracker.


Report New Errata