Yaron Sheffer writes: > > 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).
Yes, that clarification might be better, i.e. the whole pararaph would be then this: In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened when the initiator processes a response response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a DELETE payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them. > > > 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. Yes there is responses and reference to Tiger hash function, but as the RFC2104 works for any generic hash it works also with Tiger, and I understood from Paul's message that he was ok with the RFC2104 reference and I do not think we need separate reference for each algorithm. We have some of those references, and in some case we refer to RFC which has references to the algorithm and in some cases (IDEA) we have both, i.e. both reference to the RFC having reference to the algorithm description and the direct reference to the algorithm reference. I think TIGER is the only algorithm where we do not have such reference (either direct or inderect), so it might be good to add reference for it. > > > 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. Perhaps, but in the general I do not expect any kind of automatic parsing of those INVALID_SELECTORS messages, so this is not so important. In most cases I think the implementations will most likely just audit and log the INVALID_SELECTORS notification and put the notify data in the log file too, so adminstrator can check that later. INVALID_SELECTORS message usually means that one end is not following specification. If you want to provide some kind of guidance, I think that is ok, but I do not think we should waste too much time working on it. > > > 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"? No. The prefix len is not really meaningful in the INTERNALIP6_ADDRESS, in the same way as INTERNAL_IP4_NETMASK is not really meaningful. The gateway knows the real prefix len it has, and will replace the prefix with the one it has regardless what prefixlen was requested by the client. I.e. if client had the 2001:1bc8:100d:2:21d:9ff:fea5:c19a/64 before (i.e. the server gave that address last time etc), then it sends request saying: INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) Server might respond with any of the following: INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:21d:9ff:fea5:c19a/64) Keep the same address, if it s free. INTERNAL_IP6_ADDRESS(2001:1bc8:100d:ff00:21d:9ff:fea5:c19a/64) Keep the same /48 prefix (2001:1bc8:100d::/48), but change the subnet inside it from 0002 to for example ff00, but keep the lower 64 bits. INTERNAL_IP6_ADDRESS(2001:1234:5678:0:21d:9ff:fea5:c19a/64) If server has multiple /48 prefixes (for example 2001:1234:5678::/48 in addition the 2001:1bc8:100d::/48 listed before), it can change the prefix and also subnet inside it or keep the same subnet. INTERNAL_IP6_ADDRESS(2001:1bc8:100d:2:3333:4444:5555:6666:/64) Server might want to change the lower 64-bits for any reason, for example if the address requested is still in use (for example the same machine has requested it before reboot, and the old IKE SA was not yet deleted, thus the address is still in use for that IKE SA), or for example to randomize the lower 64-bits to hide the fact that this is same machine than before etc. or the server can also do something else... :-) Anyways the prefix length request and reply is not really meaningful. In reply it has same meaning as INTERNAL_IP4_NETMASK has. In request it is just whatever the server returned last time. I would except it to be /64 always... >From draft-ietf-ipsecme-ikev2bis-07: ---------------------------------------------------------------------- o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and response messages (e.g., 255.255.255.0), and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET containing the same information ("send traffic to these addresses through me"), but also implies a link boundary. For instance, the client could use its own address and the netmask to calculate the broadcast address of the link. An empty INTERNAL_IP4_NETMASK attribute can be included in a CFG_REQUEST to request this information (although the gateway can send the information even when not requested). Non-empty values for this attribute in a CFG_REQUEST do not make sense and thus MUST NOT be included. ... The INTERNAL_IP6_ADDRESS attribute also contains a prefix length field. When used in a CFG_REPLY, this corresponds to the INTERNAL_IP4_NETMASK attribute in the IPv4 case. ---------------------------------------------------------------------- > This is not clear from the existing text. True, but as we have already work in progress to change the whole IPv6 address allocation situation, I do not think we should change this text in IKEv2bis. > > > 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. So you think group 2 is not common use with 3DES? The text is very careful about not saying anything about the actual strength of either algorithm (group 2 or 3DES), just comments that it is common use with 3DES (not that its strength match with it), and that it needs to be used with random exponent longer than 200 bits for that use. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
