RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 717
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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

Report New Errata



Advanced Search