draft-zhang-btns-icmp-sec-extension-01

Hi, dear all,

With great help of Alfred and other members of the group,
the 2nd version of the I-D (Extension of ICMP Security
Failures Messages) has been finished. Great thanks to them!


Any comments from you are appreciated.

Best regards,
Qingshan

-----Original Message-----
From: Alfred HÎnes [mailto:ahtr-sys.de] 
Sent: ÐÇÆÚÁù 2007Äê1ÔÂ13ÈÕ 22:57
To: CTO ZHANG Qingshan
Subject: draft-zhang-btns-icmp-sec-extension-00

Hello,
after studying your Internet-Draft,
    draft-zhang-btns-icmp-sec-extension-00 , I would like to
point out some substantial issues with that draft, and
propose a couple of textual enhancements and corrections to
textual issues.

I'll undertake an almost linear walk-through of the text.
Snippits are taken literally, and when showing context for
proposed changes, I make use of the shorthand notation:

   <original text>
---
   <modified text>

or, if blank lines appear in the snippits:

----------- snip ----------
   <original text>
   <original text>
   <original text>
^v^v^v^v^v^v^v^v^v^v^v^v^v^
   <modified text>
   <modified text>
   <modified text>
----------- snip ----------

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 generally been re-adjusted to match I-D /
RFC formatting rules, where appropriate.
I also have tried to adopt other currently enforced RFC-Ed.
policy (e.g., punctuation style).


(1)  Abstract

Please, either use "sub-types" or
"subtypes" instead of "sub types"
(and similarly for "sub kind" etc.).

   RFC2521 defines ICMP security failures messages for
indicating
   failures when using IP Security Protocols (AH and ESP). 
This
   document presents extension of those messages, which make
use of some
   reserved field to specify sub types of failures.
---
|  RFC 2521 defines ICMP security failures messages for
indicating
   failures when using IP Security Protocols (AH and ESP). 
This
   document presents extension of those messages that make
use of some
|  reserved field to specify subtypes of failures.


(2)  Section 2

   [RFC2521] is intended for use with the Internet Security
Protocols
   ([RFC2401] etc.) for authentication and privacy.  These
messages
|  covers all the failure types of IPSec traffic, but the
granularity of
   some failures specified in the failure messages is larger
than that
|  provided by IPSec protocol suite.
---
   [RFC2521] is intended for use with the Internet Security
Protocols
   ([RFC2401] etc.) for authentication and privacy.  These
messages
|  cover all the failure types of IPSec traffic, but the
granularity of
   some failures specified in the failure messages is larger
than that
|  provided by the IPSec protocol suite.

|  In order to make full use of the IPSec traffic
granularity, extension
   of the failure messages is introduced in this document,
which
   subdivides some failure types according to the minimum
granularity of
   IPSec traffic.
---
|  In order to make full use of the IPSec traffic
granularity, an
   extension of the failure messages is introduced in this
document,
   which subdivides some failure types according to the
minimum
   granularity of IPSec traffic.


(3)  Section 3

In the figure, I propose to add the usual ruler lines above,
andbetter reflect the current standard; in the explanation,
I recommend making clear from the beginning what is taken
unchanged from RFC 2521.

Finally, I recommend to perform indentation to enhance the
readability, and I have added a few additional
clarifications, as well.

Thus:

   Below is the format of ICMP security failures messages
with the
   subcode extension.  It is different from the original
format
   ([RFC2521]) at the reserved field.  The first half of the
reserved
   field is used as the "Subcode" field, which
indicates sub types of
   security failures specified by the "Code"
field.
---
   Below is the format of ICMP security failures messages
with the
   subcode extension.  It is different from the original
format
   ([RFC2521]) at the reserved field.  The first half of the
reserved
|  field is used as the "Subcode" field, which
indicates sub-types of
   security failures specified by the "Code"
field.

----------- snip ----------
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |     Type      |     Code      |          Checksum      
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |   Subcode     |   Reserved    |          Pointer       
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |                                                        
      |
   ~     Original Internet Headers + 64 bits of Payload     
      ~
   |                                                        
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
---
|   0                   1                   2               
   3
|   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |     Type      |     Code      |          Checksum      
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |   Subcode     |   Reserved    |          Pointer       
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
   |                                                        
      |
|  ~   Original Internet Headers + 64 bits of Payload (or
more)    ~
   |                                                        
      |
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+

----------- snip ----------
   Type: 40

   Code: Indicates the kind of failure:

   0 = Bad SPI

   1 = Authentication Failed

   2 = Decompression Failed

   3 = Decryption Failed

   4 = Need Authentication

   5 = Need Authorization
^v^v^v^v^v^v^v^v^v^v^v^v^v^
   Type: 40

   Code: Indicates the kind of failure, as specified in RFC
2521:

         0 = Bad SPI
         1 = Authentication Failed
         2 = Decompression Failed
         3 = Decryption Failed
         4 = Need Authentication
         5 = Need Authorization
----------- snip ----------

----------- snip ----------
   Subcode: Indicates the sub kind of failure:

   0 = Not Classified

   If Code = 0~4, values of the subcode MAY be defined in
future if
   necessary.

   If Code = 5, the subcode is defined as below:

   1 = Name Unauthorized

   2 = Data Sensitivity Level Unauthorized

   3 = Transport Layer Protocol Unauthorized

   4 = Source Port Unauthorized

   5 = Destination Port Unauthorized

   4 = Source Port Unauthorized

   5 = Destination Port Unauthorized

   Otherwise, the subcode MUST be set to zero.
^v^v^v^v^v^v^v^v^v^v^v^v^v^
   Subcode: Indicates the sub-kind of failure.
|     There's a distinct namespace for subcode values, per
Code.
|     For all values of Code, the following is defined:

         0 = Not Classified

|     If Code = 0..4, other values of the subcode MAY be
defined in the
      future if necessary.

|     If Code = 5, the following subcode values are
defined:

         1 = Name Unauthorized
         2 = Data Sensitivity Level Unauthorized
         3 = Transport Layer Protocol Unauthorized
         4 = Source Port Unauthorized
         5 = Destination Port Unauthorized

      Otherwise, the subcode MUST be set to zero.
----------- snip ----------

And the final paragraph of the section:

   The values of subcode for "Need Authorization"
are defined according
   to different selectors provided by IPSec, which determine
the
   granularity of IPSec traffics.  Meanings of these values
are
   elaborated as below.
---
   The values of subcode for "Need Authorization"
are defined according
   to different selectors provided by IPSec, which determine
the
|  granularity of IPSec traffics.  The meanings of these
values are
   elaborated as below.


(4)  Section 3.1

   This value is used for all failure types (Code=0~5).  It
indicates
   that a received datagram will not be accepted because
there is a
   failure with the datagram, but the receptor does not
specify sub
   types of this failure.
---
   This value is used for all failure types (Code=0~5).  It
indicates
   that a received datagram will not be accepted because
there is a
|  failure with the datagram, but the receptor does not
specify the  
| sub-types of this failure.


(5)  Section 3.2

I try on a clarification.
Perhaps, the whole section needs updates and clarifications
for
IKEv2 [RFC4306].

   Indicates that a received datagram will not be accepted
because
   either no name information, or inappropriate name
information is
   presented.  (There are 2 cases of name information
supported in IPSec
   DOI - User ID and System Name.)
---
|  Indicates that a received IKE datagram will not be
accepted because
   either no name information, or inappropriate name
information is
|  presented.  (There are 2 cases of name information
supported in the  
| IPSec DoI for ISAKMP [RFC2407] - User ID and System
Name.)

I do not understand what you mean by the next paragraph:

   In the case of receipt of a datagram with an ESP header,
the name
   information is "OPAQUE" before decryption.  The
receptor SHOULD check
   the name information in this datagram after decryption,
and generate
   a "Name Unauthorized" message if the name
information of the datagram
   mismatches the name selector.

As far as I see, authentication and authorization are dealt
entirely with in the establishment of the IPsec SA,
typically making use of the key management protocols (IKEv1
or IKEv2 -- there are other proposals).
In IKE, the matters of authentication and authorization for
SAs is managed by the IPsec databases, SPD, SAD, and PAD.
IPsec protocol messages just encapsulate the traffic within
the IPsec SA identified by the SPI in the ESP (or AH) header
inserted, and the IPsec architecture does not include any
further authorization checks beyond matching against the SA
selectors stored in the SAD.  I am not aware of any
"name information" contained per-packet in
ESP/AH.

Note also, for the first paragraph above: RFC 2521 appears
to be
*not* applicable to key management traffic (IKE etc.), it
apparently is only intended for packets protected by IPsec
SAs (ESP/AH packets).
IKE packets are *not* protected by an IPsec SA, the
bootstrapping of protection is granted for by the IKE SA
carrying IKE packets.


(6)  Section 3.3

The selector "data sensitivity level" has been
deprecated by the current IPsec Architecture document
[RFC4301].

The whole section is void, and the subcode value 2 assigned
is obsolete from the beginning.


(7)  References

Most References given are much outdated.  Update as
follows:
  [RFC2401]  -->  [RFC4301]
  [RFC2402]  -->  [RFC4302]
  [RFC2406]  -->  [RFC4303]
  [RFC2463]  -->  [RFC4443]

Urgently add approriate Normative References for ICMP(v4).
The Ref. [RFC2463] does not appear in the text -- see (8)
below!

Add Ref's for IKEv2: [RFC4306], and IKEv1 (if still deemed
necessary): [RFC2407], [RFC2408], and [RFC2409].
The latter cannot be specified as Normative References
because the RFCs have been obsoleted last year.

Delete Ref [RFC3232] -- it does not appear in the body of
the draft, and give more specific reference to the
particular IANA registry/ registries affected.


(8)  IPv6 awareness

This is perhaps the most important topic of all:

Your memo will perhaps not have any chance of being accepted
in the IETF/IESG, as long it does not also specify a
solution for IPv6, of the problem it supposes to solve for
IPv4, unless it
*clearly* explains why this problem is not applicable to
IPv6.

It does not suffice to include only a Ref. to the
(previous)
ICMPv6 specification without making use of that Ref. in the
text, and without giving any ICPMv6 specific details.


(9)  IANA Considerations

The draft does not contain the *required* IANA
Considerations section.  It really should -- detailing the
new sub-registry of the icmp-parameters registry, and
setting the policy for any further allocations therein.


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:  ahTR-Sys.de
                    |
+------------------------+----------------------------------
----------+



_______________________________________________