Hi Tero, please see below.
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, January 25, 2010 13:31
> To: Yaron Sheffer
> Cc: IPsecme WG
> Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards
>
> 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.
>
Yes, I misunderstood the parentheses in that last paragraph of 2.21.2. It would
have been clearer if we said "in case an error happened when the initiator
processes a response to IKE_AUTH).
> > 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
No, there were follow-ups to that message, including one that gave the
reference that we should include in bis:
Ross Anderson, Eli Biham, Tiger: A Fast New Hash Function, Fast Software
Encryption 3, 1996, LNCS 1039.
>
> > 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).
I think we should give better guidance than a hint.
>
> > 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.
So you are saying the responder (the IRAS) should interpret the prefix-length
field as "the last X octets are the ones that I want retained in the new
address, if that is possible"? This is not clear from the existing text.
>
> > 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?
The one about Group 2. But I accept Pasi's judgment that this would be a
rewrite of RFC 4307, i.e. let's forget it for now.
> --
> kivi...@iki.fi
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
