Yaron Sheffer writes:
> 2.21.: EAP Failure cases are missing altogether. Also, the first
> paragraph says that if an auth failure occurs at the responder,
> AUTHENTICATION_FAILED is included in the protected response (to
> IKE_AUTH),
Yes.
> while the last paragraph says it's a separate
> Informational exchange.
Where does it say that if failure occurs at the responder you are
allowed to use separate INFORMATIONAL exchange? It was supposed to say
that in case the failure occurs at the INITIATOR (i.e. parsing the
response packet) then it MAY use INFORMATIONAL exchange.
> 2.24: what's this section (ECN) doing here? It is 100% IPsec,
> nothing to do with IKE. If there's a reason, let's explain it in
> the text.
It is here because if IKEv2 is used then ECN behavior is implictly
mandated by just using IKEv2. In IKEv1 we had negotiation ability for
it, but not in IKEv2. I think the current text already explains this:
ECN support for IPsec tunnels for IKEv1-
based IPsec requires multiple operating modes and negotiation (see
[ECN]). IKEv2 simplifies this situation by requiring that ECN be
usable in the outer IP headers of all tunnel-mode Child SAs created
by IKEv2. Specifically, tunnel encapsulators and decapsulators for
all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
functionality option for tunnels specified in [ECN] and MUST
implement the tunnel encapsulation and decapsulation processing
specified in [IPSECARCH] to prevent discarding of ECN congestion
indications.
> 3.3.2: Tiger - we closed issue #33, but according to the text of the
> issue, should have left the algorithm "unspecified". Which I think
> would be much more accurate.
The "Not done" part is from the time Paul opened the issue, not the
final outcome from the issue.
Final outcome can be found from here:
http://www.ietf.org/mail-archive/web/ipsec/current/msg03187.html
> 3.3.5: "Attributes described as fixed length MUST NOT be encoded
> using the variable-length encoding." This cannot be correct, a new
> 4-octet attribute will have to be encoded as variable-length. It
> won't fit into the other format.
This should use "TV" and "TLV" format text instead:
The only currently defined attribute type (Key Length) is using TV
encoding; the TLV encoding specification is included only for
future extensions. Attributes described as using TV encoding MUST
NOT be encoded using the TLV encoding. Attributes described as
using TLV encoding MUST NOT be encoded as using TV encoding even if
their value can fit into two octets. NOTE: This is a change from
IKEv1, where increased flexibility may have simplified the composer
of messages but certainly complicated the parser.
> 3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025?
> It's not used anywhere, but still...
I do not think the DNS Signed Key mans the same as IPSECKEY RR
specified in the RFC4025. Or it could be it means, but nobody knows,
thus I think it is correct to keep it UNSPECIFIED, especially as this
value dates back to the RFC2408 which predates RFC4025 and RFC4025
does not mention that it actually specifies what this format in IKE
should mean.
> 3.7: "If multiple CAs are trusted and the certificate encoding does
> not allow a list, then multiple Certificate Request payloads would
> need to be transmitted." This doesn't make sense: we are not sending
> the cert itself here. we're just sending an encoding on a CA.
> Moreover, the text further down indicates that the CA field is
> *always* a list - at least for the defined cert types (4, 12, 13).
> Overall, this looks like a placeholder, and I suggest to delete the
> sentence.
It is placeholder for other formats not defined in this document, i.e.
it explictly says that if some future certificate encoding type
defines format how certificate authorities are sent inside the CERTREQ
payload and that newly defined format does not allow list then
multiple CERTREQ payloads are sent.
As all currently defined certificate encodings do allow list, this
does not affect them.
I suggest keeping that text.
> 3.10.1: INVALID_SELECTORS is underspecified. It should be rate
> limited (I suppose), also, how long is the packet fragment included
> in the notification?
Yes, most likely it should be rate limited, but that is not hard
requirement, as this is caused when authenticated entity does
something incorrect (i.e includes traffic that is not allowed in this
SA).
Also RFC4301 already mentions rate limitation etc:
----------------------------------------------------------------------
5. If an IPsec system receives an inbound packet on an SA and the
packet's header fields are not consistent with the selectors for
the SA, it MUST discard the packet. This is an auditable event.
The audit log entry for this event SHOULD include the current
date/time, SPI, IPsec protocol(s), source and destination of the
packet, any other selector values of the packet that are
available, and the selector values from the relevant SAD entry.
The system SHOULD also be capable of generating and sending an
IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
indicating that the received packet was discarded because of
failure to pass selector checks.
To minimize the impact of a DoS attack, or a mis-configured peer, the
IPsec system SHOULD include a management control to allow an
administrator to configure the IPsec implementation to send or not
send this IKE notification, and if this facility is selected, to rate
limit the transmission of such notifications.
----------------------------------------------------------------------
I think the as in ICMP message provides good enough hint how the
packet fragment should be included (i.e. not too long as it would
waste bandwidth, but long enough to allow other end to see all
selectors).
> In addition, Sec. 2.21.2 implies that it is sent during Child SA
> negotiation, which is not what 3.10.1 is saying.
Yes, the 2.21.2 should not include INVALID_SELECTORS in its list of
notify paylaods there, so changing
Specifically, a
responder may include all the payloads associated with authentication
(IDr, Cert and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
authentication because of this.
to
Specifically, a
responder may include all the payloads associated with
authentication (IDr, Cert and AUTH) while sending error
notifications for the piggybacked exchanges (FAILED_CP_REQUIRED
NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
authentication because of this.
is required.
> 3.15.1: "With IPv6, a requestor MAY supply the low-order address
> octets it wants to use." This means to me that you *don't* provide
> all 16 octets. But according to the table, the field is a
> fixed-length 16 octets!
No, you always include full 16 octets, but you might only fill in the
lower 8 octets. You can also fill in the full 16 octets, if you have
address from previous runs.
I.e. you can send following INTERNAL_IP6_ADDRESS payloads in the
CFG_REQUEST:
INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) = 17 bytes
INTERNAL_IP6_ADDRESS(::21d:9ff:fea5:c19a/64) = 17 bytes
INTERNAL_IP6_ADDRESS() = 0 bytes.
> 5: unfortunately we have to revise the text about group strengths -
> or remove it altogether. It is non-normative, so it's probably best
> to eliminate it.
Why is that, and what text you mean?
I still think group 2 (1024-bit group) is common for use with 3DES.
Also group 5 (1536-bit group) does provide more security than group 2
(1024-bit group).
Also group 1 (768-bit group) is for historic purposes only and does
not provide sufficient strength except for use with DES, which is also
for historic use only.
So which of those statement requires revising?
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
