Hi Yoav, On Fri, Feb 19, 2010 at 3:22 AM, Yoav Nir <y...@checkpoint.com> wrote:
> Hi all. > > There are only three issues this time, because this is the last batch. > > Issue #173 - Trigger packets should not be required > =================================================== > In a few places in the new section 2.23.1 in IKEv2bis, it says that one > must have a trigger packet when starting negotiation. This assumption > should be removed so as not to cause new requirements in IKEv2bis: > there is no requirement for trigger packets in RFC 4306 or in the rest > of IKEv2bis. > > - "When the client starts creating the IKEv2 SA and Child SA for sending > traffic to the server, it has a triggering packet with source IP address > of IP1, and a destination IP address of IPN2" should be changed to > "...it may have a triggering packet...". > > - "The first traffic selector of TSi and TSr SHOULD have very specific > traffic selectors including protocol and port numbers from the packet > triggering the request" should be changed to "...SHOULD have very > specific traffic selectors including protocol and port numbers, such as > from the packet...". > > - The same change is made in the third bullet of the client list near > the end of the section. > > I fully agree with this, and I think the document should be updated as > suggested here. Moreover, section 2.9 describes the SINGLE_PAIR_REQUIRED > error notification. Obviously you can't have both a trigger packet and a > single_pair, so one of them should go. Trigger packets are at best > recommended, not mandatory. > > > > Issue #174 - How to behave when EAP identity is not send by AAA > =============================================================== > In ikev2bis07 > > ----- ikev2-bis-07 section 2.16, last paragraph ------------ > > When the initiator authentication uses EAP, it is possible that the > contents of the IDi payload is used only for AAA routing purposes and > selecting which EAP method to use. This value may be different from the > identity authenticated by the EAP method. It is important that policy > look ups and access control decisions use the actual authenticated > identity. Often the EAP server is implemented in a separate AAA server > that communicates with the IKEv2 responder. In this case, the > authenticated identity has to be sent from the AAA server to the IKEv2 > responder. > > It says the authenticated EAP identity "has to" be send from AAA server, > my interpretation and implementation "has to" is obvious MUST. If AAA > doesn't send the authenticated EAP identity, what should be the > behavior? Also, what if AAA server EAP server is not AAA server? > > > There has been a lively discussion about this (a thread titled > "Regarding EAP identity"). I can't say that the thread reached any firm > conclusion, but a lot of ground has been covered about how AAA servers > work, and about whether or not they communicate to the server something > other then identity, such as policy. Despite the fact that the second A > in AAA stands for "authorization", it was generally agreed that it is > still the job of the IKE gateway to enforce policy, and if that policy > comes from a AAA server, that is totally outside the scope of this > document. > > So in conclusion, how about replacing "the authenticated identity has to > be sent" with "the authenticated identity, if different from that in the > IDi payload, has to be sent..." ? Would that satisfy everyone? > > "the authenticated identity, if different from that in the IDi payload, MUST/SHOULD be sent..." would be good. > > Issue #175 - Better wording for NAT mobility issues > =================================================== > The last bullet in 2.23 is confusing. A proposed rewrite is: > > Old: > There are cases where a NAT box decides to remove mappings that are > still alive (for example, the keepalive interval is too long, or the NAT > box is rebooted). To recover in these cases, hosts that do not support > other methods of recovery such as MOBIKE [MOBIKE], and that are not > behind a NAT, SHOULD send all packets (including retransmission packets) > to the IP address and port from the last valid authenticated packet from > the other end (that is, they should dynamically update the address). A > host behind a NAT SHOULD NOT do this because it opens a possible denial > of service attack. Any authenticated IKE packet or any authenticated > UDP- encapsulated ESP packet can be used to detect that the IP address > or the port has changed. When IKEv2 is used with MOBIKE, dynamically > updating the addresses described above interferes with MOBIKE's way of > recovering from the same situation. See Section 3.8 of [MOBIKE] for more > information. > > New: > There are cases where a NAT box decides to remove mappings that are > still alive (for example, the keepalive interval is too long, or the NAT > box is rebooted). This will be apparent to a host if it receives a > packet whose integrity protection validates, but has a different port, > address, or both from the one that was associated with the SA in the > validated packet. When such a validated packet is found, a host that > does not support other methods of recovery such as MOBIKE [MOBIKE], and > that is not behind a NAT, SHOULD send all packets (including > retransmission packets) to the IP address and port in the validated > packet, and SHOULD store this as the new address and port combination > for the SA (that is, they SHOULD dynamically update the address). A host > behind a NAT SHOULD NOT do this type of dynamic address update if a > validated packet has different port and/or address values because it > opens a possible denial of service attack (such as allowing an attacker > to break the connection with a single packet). When IKEv2 is used with > MOBIKE, dynamically updating the addresses described above interferes > with MOBIKE's way of recovering from the same situation. See Section 3.8 > of [MOBIKE] for more information. > > No discussion, but I like the change. Anyone objects? > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
