Subject: [IPsec] Just three more issues for IKEv2bis

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Feb 2010 23:52:35 +0200

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?

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?

---

From: Raj Singh <[email-masked]>
Date: Fri, 19 Feb 2010 12:55:56 +0530

Hi Yoav,

On Fri, Feb 19, 2010 at 3:22 AM, Yoav Nir <[email-masked]> wrote:

> "the authenticated identity, if different from that in the
IDi payload, MUST/SHOULD be sent..." would be good.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Feb 2010 13:10:26 +0200

> Issue #173 - Trigger packets should not be required

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.

> specific traffic selectors including protocol and port numbers, such as

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

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.

> 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
> 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.

> 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.

> 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

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". 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Feb 2010 08:22:51 -0800

>> "...it may have a triggering packet...".

We disagree.

>then it does not have triggering packet.

We disagree. If a client starts creating an IKEv2SA for sending traffic, it may do that because it knows it will have packets in the future, but does not have them when it sets up the SA. An autostart rule that is based on *knowing* that something will come in the future is still creating IKEv2 SA for sending traffic.

I still feel strongly that the wording as it stands imposes a new requirement in IKEv2bis, and that is inappropriate to do so.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Fri, 19 Feb 2010 11:36:44 -0500

Am reading this right?

> >> "...it may have a triggering packet...".

Tero -- why precisely is "may have a triggering packet" wrong?

The change is to say, "may have a triggering packet," right?  If I understand

AND what Paul says:

> We disagree. If a client starts creating an IKEv2SA for sending traffic, it
> may do that because it knows it will have packets in the future, but does
> not have them when it sets up the SA. An autostart rule that is based on
> *knowing* that something will come in the future is still creating IKEv2 SA
> for sending traffic.

are both true.  If there's disagreement, it's only because you two are
tassling over what constitutes "creating an IKEv2 SA for sending traffic."
Sure an IKEv2 SA can be used for sending traffic, but creating one doesn't
have to be the result of an outbound packet that needs AH or ESP protection.

Both of you acknowledge, I believe, that creating an IKEv2 SA can occur
without a triggering packet (whether it's by some autostart rule, or
some explicit administrator action).

Am I missing something else?  Ahh, I think I am.  After reviewing Tero's

>      selectors including protocol and port numbers from the packet

So Tero --> you agree that an IKEv2 SA can be created w/o a triggering
packet, but the changes need to be localized to only certain portions of
4301bis, while the other portions of text only apply when we KNOW a
triggering packet would be present?

Just checking,
Dan

---

From: Yoav Nir <[email-masked]>
Date: Sun, 21 Feb 2010 10:23:43 +0200

Hi Raj

> IDi payload, MUST/SHOULD be sent..." would be good.

Two reasons why I disagree:
1. This is a new MUST/SHOULD requirement, and we're very wary of doing that.
2. This is a requirement for the AAA server. It really says that the AAA server MUST/SHOULD send the identity. In this document, we're specifying the behavior of the IKE gateway, not the AAA server, so RFC 2119 language is not appropriate. This is simply stating fact, that if the authenticated identity is different, it has to come from the EAP server. In any case, the IKE gateway cannot enforce this - it doesn't know about a different authenticated identity unless the EAP server tells it. 

All we can say is that the IKE gateway should treat the IDi as the authenticated identity, unless the EAP server tells it something different.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Feb 2010 12:51:50 +0200

> Tero -- why precisely is "may have a triggering packet" wrong?

Becahse it client starts sending traffic to the server, it has packet.
It is not necessarely wrong, but it sound funny to say "I have packet
I am sending from client to server, so I may have a packet..."

> tassling over what constitutes "creating an IKEv2 SA for sending traffic."

I expect so. As this paragraph does not cover the other cases than
when you have triggering packet, I do not think it is good idea to
confuse the things to add text that looks like it could be applied in
other cases too.

> have to be the result of an outbound packet that needs AH or ESP protection.

Actually the text about "IKEv2 SA" is wrong, as IKEv2 SAs do not have
traffic selectors, it should only talk about Child SAs, i.e. perhaps
the better text would be:

  When the client starts creating a Child SA for protecting packet to
  be sent to the server, it has a triggering packet, it has a
  triggering packet with source IP address of IP1, and destination IP
  address of IPN2.

> some explicit administrator action).

Yes, but this paragraph does not talk about those cases, it only
applies when you have triggering packet, i.e. when you are creating
Child SA because of traffic you are sending. 

> packet,

Yes.

> but the changes need to be localized to only certain portions of

Yes. There is text already covering the cases where you do not have
packet. There is also text where you do have a triggering packet.

This whole section we are talking here is very special case only
covering cases where following things are true:

      - We are using NAT-T (i.e. there is NAT between).
      - We are talking about transport mode

The example given generalizes this to cases where

      - We have two NAT boxes between the client and server

and this paragraph covers the (most common case as we are talking
transport mode NAT-T here):

      - We have packet we are going to protect, and need to create
        Child SA for it, i.e. we do have triggering packet.

The first sentence could also be written in other way around:

   When we do have a triggering packet with source IP address of IP1,
   and a destination IP address of IPN2, i.e. when client starts
   creating Child SA for sending that packet to the server, client
   host's PAD and SPD needs to have configuration matching those
   addresss (or wildcard entries covering them).

but this leads quite complex text.

Also as we are talking ONLY transport mode NAT-T here, the autostart
rules are not very common. Transport mode is used for host to host
traffic, and I do not really see that you have all your machines set
up to create Child SAs to all hosts they might be talking before
actually sending traffic to them. 
-- 
[email-masked]