CTO ZHANG Qingshan
2007-03-02 02:58:33 UTC
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:ah at tr-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: ah at TR-Sys.de |
+------------------------+--------------------------------------------+
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-zhang-btns-icpm-sec-extension-01.txt
Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070302/e343d030/draft-zhang-btns-icpm-sec-extension-01-0001.txt
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:ah at tr-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: ah at TR-Sys.de |
+------------------------+--------------------------------------------+
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-zhang-btns-icpm-sec-extension-01.txt
Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070302/e343d030/draft-zhang-btns-icpm-sec-extension-01-0001.txt