Yoav Nir writes:
> 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...".
This change is wrong.
If client starts creating IKEv2 SA for sending traffic, it will have
trigger packet. If it creates IKEv2 SA for some other reason (i.e not
because of trigger packet, but because of autostart rule or similar),
then it does not have triggering packet.
You can see this as if you look at the next paragraph, it says you use
those addresses when searching from PAD and SPD:
... Its PAD and
SPD needs to have configuration matching those addresses (or wildcard
entries covering them).
Note, that this whole paragraph is for client to server transport mode
case, it does not apply to any other cases (the previous paragraph
says that).
So I think that text needs to be kept as it is now.
> - "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...".
This is continuation of the same client to server transport mode case
where SAs are created because client wands to send traffic to server,
thus the client DOES have triggering packet. I would keep the original
text as it is, as you do have triggering packet in this case, and in
that case you should take the first traffic selector information from
there, not anywhere else.
The language is SHOULD so in case you have some good reason to ignore
the triggering packet, and take some other data to fill in to
very specific traffic selector (or to leave it out completely), you
can still do that.
All of that paragraph is for the case where you do have packet. It
does not cover other cases.
> - The same change is made in the third bullet of the client list near
> the end of the section.
This is the one that needs to be changed, as that third bullet is not
only specific to triggering packet case, it is in the generic
processing section, i.e. that bullet should be changed to:
- If SA is created because of the data packet, then the first TSi
and TSr traffic selectors SHOULD have very specific traffic
selectors including protocol and port numbers from the packet
triggering the request.
> I fully agree with this, and I think the document should be updated as
> suggested here.
I think the last change is ok, but first two should not be done.
> 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.
No, both of them are needed. Trigger packet only applies when you
create SA because of traffic. If you create SA without having traffic,
you do not have triggering packet, and in that case
SINGLE_PAIR_REQUIRED error is the way for other end to indicate that
it does want to have SAs created only because of traffic, i.e. it
wants to have very specific traffic selectors.
> Trigger packets are at best recommended, not mandatory.
They used to be RECOMMENDED (i.e. SHOULD), but that was removed and I
think we already agreed adding them back to RECOMMENDED/SHOULD.
> 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.
It is not MUST, it is "has to", which means that as IKEv2 responder
needs to match the authenticated identity against policy, it needs to
somehow get that authenticated identity from the entity which did
authentication. If you have AAA server then that is the one who knows
the final authenticated identity, so it has to send it IKEv2 responder
using whatever means needed.
> 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?
This question is completely outside the scope of this document. We do
not specify IKEv2 and AAA interaction here, we just say that IKEv2
responder needs to get that authenticated identity and the whatever
entity who does authentication needs to communicate it to IKEv2, but
as none of this is visible on the outside (i.e. to the initiator of
the IKEv2 SA) it does not matter what they do.
> 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?
I think the current text is ok, but that text is also ok (if the
identities are same, then it does not matter which one we use).
> 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?
If we are going to define the last valid authenticated packet better,
then we should also include the fact that the packet MUST be new, i.e.
it cannot be old replayed packet whose "integrity protection
validates".
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
