Hi all.
5 more issues.
Issue #153 - List of EAP methods
================================
3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens
of methods now in the IANA registry, many of which are preferable to the ones
mentioned here.
I agree, especially since we have a SHOULD NOT for using methods 4-6. I suggest
removing the entire table (and the sentence "The following types are
defined..." which precedes it. Instead, change the following paragraph to read
as follows (added comment in parenthesis):
Note that since IKE passes an indication of initiator identity in
message 3 of the protocol, the responder should not send EAP Identity
requests (type 1). The initiator may, however, respond to such requests
if it receives them.
Issue #154 - Sending dummy messages during rekey
================================================
Sec. 2.8: "An initiator MAY send a dummy message on a newly created SA if it
has no messages queued in order to assure the responder that the initiator is
ready to receive messages."
A dummy (higher level protocol) message on an IPsec SA is way out of scope.
Whether such messages even exist is a matter of local implementation.
Or does the document refer to "dummy ESP messages" (RFC 4303, sec. 2.6)? If so,
please add the reference.
I suspect that some implementations do not implement TFC, and so had no reason
to implement dummy messages. If this was a MUST here or even a SHOULD, I would
definitely object, but this is a MAY-level requirement.
I think we can close this by replacing "MAY send a dummy message on a newly
created SA..." with "MAY send a dummy ESP message on a newly created ESP SA..."
(added ESP twice, because there are no dummy messages in AH), and add a
normative reference to RFC 4303 - no need IMO to link from the text.
Issue #155 - SHOULD send triggering packet and interoperability
===============================================================
In the sectioon 2.9 the "SHOULD" requirement was removed for the very specific
traffic selector as fist traffic selector.
I think that "SHOULD" requirement needs to be kept, as it affects
interoperability, as if other end does not include that triggering packet then
certain policies cannot interoperate.
Also in the interops we have seen implementations who could not interoperate at
all if sender end included triggering packet (I do not know if the failure to
create Child SA was because the traffic selector containing port selectors, or
whether it was because there were multiple traffic selectors).
If there is "SHOULD" level requirement for that, then we can at least point the
other vendors to that and say, that as we SHOULD be sending that triggering
packet, then you also needs to be able to cope with it...
Old text was:
To enable the responder to choose the appropriate range in this case, if the
initiator has requested the SA due to a data packet, the initiator SHOULD
include as the first traffic selector in each of TSi and TSr a very specific
traffic selector including the addresses in the packet triggering the request.
new text in draft-ietf-ipsecme-ikev2bis-07.txt is:
If the initiator requests an SA because it wants to send a data packet,
including the specific addresses in the packet triggering the request in the
first traffic selector in both TSi and TSr enables the responder to choose the
appropriate range.
I agree with Tero here. I think the SHOULD should come back.
Issue #156 - SHOULD generate and accept which types?
====================================================
Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR,
ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says:
Two implementations will interoperate only if each can generate a type of ID
acceptable to the other. To assure maximum interoperability, implementations
MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these
types. Implementations SHOULD be capable of generating and accepting all of
these types. IPv6-capable implementations MUST additionally be configurable to
accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only
ID_IPV6_ADDR.
What does " Implementations SHOULD be capable of generating and accepting all
of these types" mean? It can't mean the four just listed, because that list of
four comes with MUSTs. If it means all the listed types, the sentence should be
changed to "Implementations SHOULD also be capable of generating ID_IPV6_ADDR,
ID_DER_ASN1_DN, and ID_DER_ASN1_GN."
Unlike the other issues in this mail, this one generated a lively debate, that
quickly went to requirements for PKIX. Valery made a (to mind mind valid) point
that the requirements in section 4 specify certificates with RSA keys, where
other algorithms are available: GOST, DSA and ECDSA. While this is a valid
point, criticism of section 4 should be in another issue, so I suggest going
with Pasi's recommendation, and keeping the text as is.
Issue #157 - Illustrate the SA payload with a diagram
=====================================================
The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
be helpful.
"The margin is too narrow for a diagram" (Trac munges my diagram and will not
take attachments). Will be sent separately to the list.
Everybody likes illustrations. Yaron made one, Tero improved on this, and
several people commented, for a total of 11 messages to the list. The final
version is Tero's, which kind of looks cramped, but I think should be added.
(what ever happened to that draft about adding graphics to RFCs?)
SA Payload
|
+------------------+---------------------------+
| |
| |
Proposal #1 Proposal #2
Proto ID = ESP (3) Proto ID = ESP (3)
SPI size = 4 SPI size = 4
7 transforms 4 transforms
SPI = 0x95903423 SPI = 0x12345678
| |
+------+-+----+------+------+------+------+ +------+------+------+
| | | | | | | | | | |
Trans Trans Trans Trans Trans Trans Trans Trans Trans Trans Trans
form form form form form form form form form form form
ENCR INTEG ENCR INTEG ENCR ESN ESN ENCR ESN ENCR ESN
ENCR AUTH ENCR AUTH ENCR No Use AES- No AES- Use
_AES _HMAC _AES _AES _AES ESN ESN GCM ESN GCM ESN
_CBC _SHA1 _CBC _XCBC _CBC 0 1 w/8 0 w/8 1
| _96 | _96 | octet octet
| | | ICV ICV
| | | | |
| | | | |
Attribute Attribute Attribute Attribute Attribute
Key Length Key Length Key Length Key Length Key Length
128 192 256 128 256
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
