Yoav Nir writes:
> Issue #153 - List of EAP methods
> ================================
> ...
> 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.
I support this change.
> 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.
How about changing it to just say that "initiator can send a dummy
message ...".
And the dummy message is not necessarely only those ones described in
the RFC4303 section 2.6, it can be anything that is suitable for the
scenario.
For example in the vpn setup where SA is set up during the autostart
it can be simple ping packet or it can be just udp packet discard port
whether is suitable for the environment.
This text is not describing what the dummy packet is, it is just
saying you might want to (and can) send such packet to make sure other
end knows you have the Child SA installed properly, so they can start
sending packets back.
I do not think we really need to change anything in this 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 agree with Tero here. I think the SHOULD should come back.
I (still) agree with myself and Yoav :-)
> 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.
I think it means the four just listed. Note, that only one of them is
MUST to send, all of them is MUST to accept. So the "SHOULD be capable
of generating" is saying that also the other four should be somethint
that can be configured to be sent. The next part "and accepting" is
not really needed as it is already covered by the MUST before.
> 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.
I agree that better keep the text as it is now.
> 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
I was not completely happy with the picture as the text in its gets so
narrow, so I was thinking what if we rotate it 90 degrees.
+------------------+----------------+
| Transform | Attribute |
| Type = ENCR(1) | Type = |
+-+ ID = | Key length(14)|
| | ENCR_AES_CBC(12)| Value = 128 |
| +------------------+----------------+
| | Transform | Attribute |
| | Type = ENCR(1) | Type = |
+-+ ID = | Key length(14)|
| | ENCR_AES_CBC(12)| Value = 192 |
| +------------------+----------------+
| | Transform | Attribute |
| | Type = ENCR(1) | Type = |
+--------------+ +-+ ID = | Key length(14)|
| Proposal #1 | | | ENCR_AES_CBC(12)| Value = 256 |
| Protocol ID | | +------------------+----------------+
+-+ = ESP (3) + | | Transform |
| | SPI size = 4 |-+-+ Type = INTEG(3) |
| | 7 transforms | + | ID = AUTH_HMAC_ |
| | SPI = | | | SHA1_96(2) |
| | 0x95903423 | | +------------------+
| +--------------+ | | Transform |
| +-+ Type = INTEG(3) |
| | | ID = AUTH_AES_ |
| | | XCBC_96(5) |
| | +------------------+
| | | Transform |
| +-+ Type = ESN (5) |
| | | ID = No ESN (0) |
| | +------------------+
| | | Transform |
| +-+ Type = ESN (5) |
+---------+ | | ID = ESN (1) |
| SA +-+ +------------------+
| Payload | | +------------------+
+---------+ | | Transform |
| +-+ Type = ESN (5) |
| | | ID = No ESN (0) |
| | +------------------+
| | | Transform |
| +-+ Type = ESN (5) |
| | | ID = ESN (1) |
| +--------------+ | +------------------+----------------+
| | Proposal #1 | | | Transform | Attribute |
| | Protocol ID | | | Type = ENCR(1) | Type = |
+-+ = ESP (3) +-+-+ ID = AES-GCM w/ | Key length(14)|
| SPI size = 4 | | | 8 octet ICV(18) | Value = 128 |
| 7 transforms | | +------------------+----------------+
| SPI = | | | Transform | Attribute |
| 0x12345678 | | | Type = ENCR(1) | Type = |
+--------------+ +-+ ID = AES-GCM w/ | Key length(14)|
| 8 octet ICV(18) | Value = 256 |
+------------------+----------------+
But that still gets too long to fit for one page, so better to keep my
previous picture.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
