Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

[Tero Kivinen]

mohamed.boucad...@orange.com writes:
> > of the cases the information in IANA registries are already in the
> > normative reference RFCs
> 
> RFCs may include stale/inaccurate values (e.g., new/deprecated
> values). The IANA registry is authoritative.

Yes, but you only need one value to actually implement standard. You
do not need to know all currently supported values. I would assume
that implementators will go to the IANA regardless whether ther
reference is normative or informative.

> I still think maintaining the refs as they are is aligned with
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/.

Yes, most likely, but ID nits still complains about it.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

[Tero Kivinen]

mohamed.boucad...@orange.com writes:
> [Med] Yes, the initiator may include a suggested ALPN (protocol) for
> example to specifically indicate it is looking for DoT (or another
> protocol). The initiator may omit the ADN, but only include service
> parameters (typically, ALPN) to indicate a preferred transport
> protocol.

I was assuming there is some way of indicating that, but I could not
quickly find any examples of that, that is why I wanted to have more
examples in this draft, so I could see what values the alpn can have
:-) 

> 
> > 
> >   CP(CFG_REQUEST) =
> >  ENCDNS_IP6(23, 1, 16,
> > (2001:DB8:99:88:77:66:55:44),
> > "doh1.example.com",
> > "???")
> > 
> > initiator requesting the responder for specific information, most
> > likely something that it got last time, and initiator proposes it
> > to the responder, in case it is still valid, and responder can
> > send that same information back if it is valid, or return
> > something else.
> 
> [Med] Yeah, but still this is just a suggested value and it is up to
> the responder to decide to honor it or not. If a preference does not
> make sense, the response will simply ignore it.

Yep, this is standard IKEv2 behavior. 

> > Btw, for the second use case where the initiator fills in some of
> > the information about the server it wants to talk to, it would be
> > usefull to allow Service Priority to be 0, and explictly mention
> > that this is not AliasMode, this is meaning that initiator does
> > not care about the exact priority or does not know the priority,
> > so it used 0 as placeholder.
> 
> [Med] The initiator can use any non-null value for the priority in
> such case. No need to relax the constraint imposed on svcpriority.

My guess is that people are going to use zero still, as that is the
obvious number to use, which is why I think it would be better to
allow that... As long as responders do not start checking that
CFG_REQUEST priority must be non zero everything is fine... 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-add-ike-07.txt

[Tero Kivinen]

mohamed.boucad...@orange.com writes:
> This version takes into account Tero's review, mainly:
> 
> * Indicate the encoding of the addresses
> * Split the ENCDNS_DIGEST_INFO figure into two
> * Add some text about CFG_ACK
> * clarify how the digest is computed
> * Add some examples
> 
> and some other minor edits. 

Can you add the other examples we had in our email exachange for
different requests, I think they provide useful information.

Also in examples it is useful to actually use names instead of
numbers, thats why I had (SHA2-256, SHA2-384, SHA2-512), and not (2,
3, 4). We are not using numbers for CP, CFG_REQUEST, or any other
fields...

Using only numbers would get really annoying:

   47(1) =
 8()
 10()
 TBA2()
 TBA3(0, (2, 3, 4))

:-)

And the ADN length field of the CFG_REPLY example is wrong, it says
16, but "doh.example.com" is only 15 characters long. Thats why my
example was using doh1.example.com :-)

I.e. it should be:

   CP(CFG_REPLY) =
 INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
 ENCDNS_IP6(1, 1, 15,
   (2001:db8:99:88:77:66:55:44),
   "doh.example.com",
   (alpn=h2 dohpath=/dns-query{?dns}))
 ENCDNS_DIGEST_INFO(0, SHA2-256,
   8b6e7a5971cc6bb0b4db5a71...)

-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Shepherd write up review for draft-ietf-ipsecme-labeled-ipsec

[Tero Kivinen]

I already send some comments, but now when I am checking the modified
draft I found some other nits, that might need to be fixed at some
point (I will still put the document forward today, authors can fix
those later when they have time, or when they have other comments
during the IETF last call etc).

In section 2.2 we have text:

   If the Security Label traffic selector is optional from a
   configuration point of view, an initiator will add the TS_SECLABEL to
   the TSi/TSr Payloads.  If the responder replies with TSi/TSr Payloads
   that include the TS_SECLABEL, than the Child SA MUST be created
   including the negotiated Security Label.  If the responder did not
   include a TS_SECLABEL in its response, then the initiator (with
   deemed the Security Label optional) will install the Child SA without
   including any Security Label.  If the initiator required the
   TS_SECLABEL, it MUST not install the Child SA and it MUST send a
   Delete notification for the Child SA so the responder can uninstall
   its Child SA.

and in section 3 we have text:

   If a TS_SECLABLE is deemed optional, the initiator SHOULD first try
   to negotiate the Child SA with the TS payload including the optional
   TS_SECLABEL.  If such a negotiation results in receiving a
   TS_UNACCEPTABLE Error Notify, it SHOULD attempt a new Child SA
   negotiation using the same TS but without the optional TS_SECLABEL.

which do not match. I suggest just removing the section 3 text, as
this is already explained in the section 2.2. Or perhaps moving the
text from section 2.2 to section 3, replacing that old section 3
paragraph with the text moved from section 2.2.

In the section 3.1 it would be nice to use properly formatted
IP-addresses. Now it looks that you are negotiating some 24-bit
FC-addresses, as your ip-addresse only has 3-bytes in them:

 TSi = ((17,24233,198.51.12-198.51.12),
(17,0,192.0.2.0-192.0.2.255),
(0,0,198.51.0-198.51.255),
TS_SECLABEL1, TS_SECLABEL2)

and
 TSi = ((0,0,198.51.0-198.51.255),
TS_SECLABEL1)

Replace 198.5.12 with something like 198.5.0.12 and 192.51.0 with
192.51.0.0 and 192.51.255 with 192.51.0.255 or something... There is
also one 192.51.0/24 in Section 3.2 that should be changed to
192.51.0.0/24.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Disabling replay protection

[Tero Kivinen]

Benjamin Schwartz writes:
> Hi IPSECME,
> 
> RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is employed,
> the receiver SHOULD notify the sender, during SA establishment, if the
> receiver will not provide anti-replay protection".
> 
> I haven't been able to find any mechanism for this in IKEv2 (or IKEv1).  Is
> there a way to do this?  Or is this a mismatch between ESP and IKEv2?

I think we discussed this during the development of the IKEv2, and it
was decided that as the replay protection is completely local matter,
there is not really reason to have that kind of notification in IKEv2.

I mean what should other end do if the other end says he will not
do anti-replay checks? I think it would be stupid to reject such
connections just because of that, and that could cause the other end
to claim to do it and still not do it just to get through the
negotiation.

In IKEv2 we tried to remove all of those parameters which are only
local matter, so that any differences in those do not cause the
negotiations to fail.

In IKEv1 there was for example the lifetime parameters sent inside the
IKEv1, and they caused lots of interoperability issues, when one send
life time of 86400 and the other one had life configured to 86700,
because there was 24h lifetime + 5 minute grace period. Or other end
had one hour and other had 8 hours. Trying to get both ends to agree
on the exact lifetimes was difficult, and thats why we removed those
in IKEv2.

I think the anti-replay protection is similar matter. What is the
actual real life reason you would want to know about that, and what do
you want to do when they do not match?
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Disabling replay protection

[Tero Kivinen]

Michael Richardson writes:
> Tero Kivinen  wrote:
> > I mean what should other end do if the other end says he will not
> > do anti-replay checks?
> 
> Not send unique relay values in the ESP.

You can already do that on multicast SAs, but for unicast SAs the
RFC4303 mandates the unique sequence numbers regardless whether the
recipient checks it or not:

  For
   a unicast SA or a single-sender multicast SA, the sender MUST
   increment this field for every transmitted packet.

and

   The field is mandatory and MUST always be present even if the
   receiver does not elect to enable the anti-replay service for a
   specific SA.  Processing of the Sequence Number field is at the
   discretion of the receiver, but all ESP implementations MUST be
   capable of performing the processing described in Sections 3.3.3 and
   3.4.3. Thus, the sender MUST always transmit this field, but the
   receiver need not act upon it (see the discussion of Sequence Number
   Verification in the "Inbound Packet Processing" section (3.4.3)
   below).

Note, that the replay values might still not be unique, as if
anti-replay is disabled then the sender can allow sequence number to
cycle, thus using duplicate sequence numbers. This is not allowed if
anti-replay is enabled.

Only thing that could be allowed by telling the other end that
anti-replay is disabled is that the sequence number is allowed to
sycle:

   If anti-replay is disabled (as noted above), the sender does not need
   to monitor or reset the counter.  However, the sender still
   increments the counter and when it reaches the maximum value, the
   counter rolls over back to zero.  (This behavior is recommended for
   multi-sender, multicast SAs, unless anti-replay mechanisms outside
   the scope of this standard are negotiated between the sender and
   receiver.)

Is that feature so important that we should have separate notification
for it?

If you want to do something else by negotiating the fact that you do
not do anti-replay protection then we need to modify the ESP and AH
too, not just add notification to IKE.

So I am saying that I do not see any real use case for just adding
notification to IKE. There could be other features that people want to
add that would also require telling the other end that replay
protection checks are disabled, but those changes would require more
things than just one notification to ike.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Disabling replay protection

[Tero Kivinen]

Benjamin Schwartz writes:
> On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson  wrote:
> 
> Tero Kivinen  wrote:
>     > I mean what should other end do if the other end says he will not
>     > do anti-replay checks?
>
> Not send unique relay values in the ESP.
> 
> Yes but mostly for AH.  My goal is related to draft-xu-risav, which would
> benefit from the ability to repeat sequence numbers in AH when replay
> protection is not required.

ESP and AH already allow that if you have multi sender situations, but
IKE does not allow nogotiating such SAs. If you use g-ikev2 to
negotiate multicast multi sender sa then I think the anti-replay is
already disabled. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Agenda for IETF 116

[Tero Kivinen]

So now it is time to start sending agenda items for the IETF 116
IPsecME WG meeting.

When you send your requests, please also include how much time you
think you would need for your topic.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [IANA #1267827] expert review for draft-ietf-ipsecme-add-ike (ikev2-parameters)

[Tero Kivinen]

David Dong via RT writes:
> Dear Tero Kivinen and Valery Smyslov (cc: ipsecme WG),
> 
> As the designated experts for the IKEv2 Configuration Payload
> Attribute Types registry, can you review the proposed registration
> in draft-ietf-ipsecme-add-ike for us? Please see 
> 
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/
> 
> The due date is March 20, 2023.
> 
> If this is OK, when the IESG approves the document for publication,
> we'll make the registration at 
> 
> https://www.iana.org/assignments/ikev2-parameters/
> 
> We'll wait for both reviewers to respond unless you tell us otherwise. 

The IANA allocations listed in the draft are ok. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsecME Agenda

[Tero Kivinen]

We have received requests for enough items to fill in the IPsecME
WG meeting slot, so here is the preliminary agenda for the IPsecME WG:

If you have any additional items that you would like to discuss, then
we need to start to tune down some of the presentations. 

--
IP Security Maintenance and Extensions (IPsecME) WG.

IETF 116 - Wednesday March 29th, 2023 15:30-17:00 JST
https://meetings.conf.meetecho.com/ietf116/?group=ipsecme&short=&item=1

Agenda

- Note Well, technical difficulties and agenda bashing - 
  Chairs (5 min)
- Document Status -
  Chairs (15 min)
- Work items
  - Issues SA TS Payloads opt draft
Paul Wouters (10 min)
  - Alternative Approach for Mixing Preshared Keys in IKEv2
for Post-quantum Security 
Valery Smyslov (10 min)
  - Extended IKEv2 Payload Format
Valery Smyslov (20 min)
  - Anti replay subspaces
Mohsin Shaikh (10 min)
  - IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension" 
Daniel Migault (10 min)
  - Traffic Selector for Internet Key Exchange
version 2 to add support Differentiated Services Field Codepoints
Daniel Migault (10 min)
- AOB + Open Mic (0 min)
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

[Tero Kivinen]

mohamed.boucad...@orange.com writes:
> > At the IETF process level, which I don't master, because of last
> > note in §4, shouldn't that document explicitly say it updates
> > RFC8598?
> 
> [Med] We discussed this point at the time (and I was personally for
> adding the header), but we didn't because the convention in ipsecme
> WG is to not add the Update header if implementations are clearly
> able to distinguish the cases when an extension is being used even
> if the extension would change the behavior defined in the existing
> RFCs. In this spec, if the initiator receives any of ENCDNS_IP*
> attributes, it will know that it should not expect the
> INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The
> note you are referring to is to make that clear.

I think we usually use updates header if implementations supporting
old RFC but not this, needs to change their behavior.

I.e., if we just add new attributes, and the implementations of old
RFC simply ignore them then everything is fine.

But my understanding is that this is not the case here, as if you send
INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with ENCDNS_IP* to
implementations supporting old RFC, then that RFC will consider this
as a fatal error, and tear down the whole IKE SA, instead of silently
ignoring ENCDNS_IP* and INTERNAL_DNS_DOMAIN attributes.

So in this case it would be better for the old Split DNS Configuration
for IKEv2 RFC8598 implementations to be changed in a way that they
recognize this situation and do not consider it as a fatal error.

Update to the RFC8598 would not be needed if the RFC8598
implementations would simply ignore both the INTERNAL_DNS_DOMAIN and
ENCDNS_IP* in configuration payload, but I do not think that is the
case here.

So question is not whether it is possible to recognize the situation,
it is what happens when you combine new and old implementations. If
things works without a need to change old implementations then no
updates is needed, if you need to update the old implentations too,
then you do need updates header.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

[Tero Kivinen]

mohamed.boucad...@orange.com writes:
> > But my understanding is that this is not the case here, as if you
> > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with
> > ENCDNS_IP* to implementations supporting old RFC,
> 
> [Med] Responders know when it will break. They will basically supply
> the encrypted DNS to initiators who indicated support as per: 
> 
>Initiators first indicate support for encrypted DNS by including
>ENCDNS_IP* attributes in their CFG_REQUEST payloads.  Responders
>supply encrypted DNS configuration by including ENCDNS_IP* attributes
>in their CFG_REPLY payloads.
> 
> If responders decide to ignore the capabilities of the initiators,
> returning **only** the ENCDNS_IP* won't break only split horizon but
> the full DNS service!

I mean if initiator proposes:

   CP(CFG_REQUEST) =
 INTERNAL_IP6_ADDRESS()
 ENCDNS_IP6()
 ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
 INTERNAL_DNS_DOMAIN()

to indicate that it only wants to talk ENCDNS server, and it does NOT
want to have normal DNS server, then responder who do not understand
ENCDNS_IP6() will see that this is against MUST in RFC8598 and as
there is no other error to use, it will most likely consider this a
malformed message (==fatal error) and return with INVALID_SYNTAX. This
will tear down the IKE SA and does not specify for the initiator why
the connection attempt failed.

Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if
INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer
them it can't add them.

Thats why it would be better for even those RFC8598 implementations
which will not support this RFC to be modified so that they will
understand ENCDNS_IP* at least so much that they understand that they
can ignore INTERNAL_DNS_DOMAIN attribute if there is no
INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply
ignore ENCDNS_IP* (is they should, as they do not understand), and
they ignore the INTERNAL_DNS_DOMAIN also because there is no
INTERNAL_IP*_DNS then the initiator will be able to connect. And then
the initiator can later do another configuration payload to fetch
normal DNS servers ip-addresses if those would be acceptable for it. 

Or, have I misunderstood the protocol somehow. I.e., what should old
responder implementation do when it receives the request like above? 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

[Tero Kivinen]

Valery Smyslov writes:
> > I mean if initiator proposes:
> > 
> >CP(CFG_REQUEST) =
> >  INTERNAL_IP6_ADDRESS()
> >  ENCDNS_IP6()
> >  ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
> >  INTERNAL_DNS_DOMAIN()
> > 
> > to indicate that it only wants to talk ENCDNS server, and it does NOT
> > want to have normal DNS server, then responder who do not understand
> > ENCDNS_IP6() will see that this is against MUST in RFC8598 and as
> > there is no other error to use, it will most likely consider this a
> > malformed message (==fatal error) and return with INVALID_SYNTAX. This
> > will tear down the IKE SA and does not specify for the initiator why
> > the connection attempt failed.
> 
> The initiator cannot force the responder to do anything (e.g. to
> explicitly provide it with the encrypted DNS info). It can only
> indicate support for this feature. So, in my understanding, the
> above set of configuration attributes indicates some problems with
> initiator (in which case fatal error is not a bad solution).
> 
> The correct request should be:
> 
> CP(CFG_REQUEST) =
>   INTERNAL_IP6_ADDRESS()
>   INTERNAL_IP6_DNS()
>   ENCDNS_IP6()
>   ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
>   INTERNAL_DNS_DOMAIN()
> 
> If the responder doesn't support this extension, it will ignore
> ENCDNS_IP6 and ENCDNS_DIGEST_INFO and return INTERNAL_IP6_DNS(...) +
> INTERNAL_DNS_DOMAIN(...).
> 
> If the responder supports this extension, it will return either
> ENCDNS_IP6(...) + ENCDNS_DIGEST_INFO(..) + INTERNAL_DNS_DOMAIN(...)
> or INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on its
> configuration (most probably the former).

This is all clear. 

> If the initiator is configured to allow only encrypted DNS, it may
> immediately delete IKE SA in case the responder returns
> INTERNAL_IP6_DNS. There is nothing more the initiator can do in this
> case.
> 
> Note, that with this approach there is no room for fatal errors, all
> protocol paths are legal with no need to update 8598.

Ok, so the note for RFC8598 behavior only applies to responder, i.e.,
responder is allowed return ENCDNS_IP* and INTERNAL_DNS_DOMAIN without
INTERNAL_IP*_DNS but inititiator needs to send request that contains
both. Perhaps the Note about the RFC8598 should be updated to say "it
is allowed for responder to include INTERNAL_DNS_DOMAIN even in the
absense of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, provided
there is ENCDNS_IP* attributes in the response." or something like
that.

Then I agree that this does not update RFC8598.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

[Tero Kivinen]

mohamed.boucad...@orange.com writes:
> As you can see at https://tinyurl.com/add-ike-latest, the note is
> updated as follows: 
> 
>   Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
>   attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
>   included.  This specification relaxes that constraint in the
>   presence of ENCDNS_IP* attributes.  That is, if ENCDNS_IP*
>   attributes are supplied, it is allowed for responders to include
>  ^^
>   INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or
>   INTERNAL_IP4_DNS) attributes.
> 
> Thanks for zooming into this. I was expecting to have this
> discussion during the IESG review. We have now a fresh thread to
> which we can refer :-) 

That looks good, and solves the issue I had with backward
compatibility. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Slices for the presentations

[Tero Kivinen]

If you presenting in the IPsecME in IETF 116, please post your slides
in pdf format with page numbers to the datatracker by the end of
Monday.

No slides posted, no time in agenda... 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsecME WG report from IETF 116

[Tero Kivinen]

This is the copy of the status update already posted to the datatracker:
https://datatracker.ietf.org/group/ipsecme/about/status/
--
IPTFS (base draft, and yang and mib drafts), TCP Encapsulation
(rfc8229bis) were published as RFC. Multiple ke is in the IESG
evaluation, and deprecation of IKEv1 and obsolete algorithms drafts
are now in RFC editor queue. Labeled IPsec is in the IETF Last call,
and IKEv2 Configuration for Encrypted DNS is waiting for AD followup.

Group Key Management still would benefit from more reviews, we got one
partial one, and few people has promised to do reviews. Submit the
draft for early directorate review to get more reviews for it, and
then submit it for publication.

Announcing Supported Authentication Methods in IKEv2 got some
comments, and needs a new revision. After that is done it is ready for
2nd WGLC.

The Optional SA & TS Payload in Child Exchange, and multi sa
performance are adopted as WG drafts, and the there has been some
implementation testing of the first one, which has resulted several
new questions and change requests to the draft.

There has been some interest on the alternate approach for mixing
preshared keys in ikev2 for post-quantum security, and there will be
WG adoption call will be done after the open issues of the draft are
solved, and new version is posted.

Quite a lot of charter items have been finished, so we should start
working on to do rechartering, and clear out old things already
finished, and add some new work to the charter.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?

[Tero Kivinen]

Paul Wouters writes:
> 
> We ran into an issue where we received a REKEY_SA notify with a bad
> protocol id, eg not ESP or AH. What do we do?
> 
> 1) CHILD_SA_NOT_FOUND, but what should we put in the proto id field?
> 0 ?  the bogus value? 
> 2) It's bad, so INVALID_SYNTAX
> 
> When doing 1, we will see:
> 
> Responder uses bad protocol id - Initiator can quietly delete child sa.
> But it forces us to send something violating the RFC.
> 
> Or Responder uses ESP or AH protocol id? Initiator will now be upset,
> and possible send a new informational with a notify with INVALID_SYNTAX
> or DELETE. If INVALID_SYNTAX, it will take down everything.
> 
> When doing 2, it guarantees everything will be taken down.
> 
> 
> Ideally, we would like to "ignore" the REKEY_SA, and leave the IKE and
> existing Child SAs up. But that means we need to lie about protocol id,
> and we currently have guards in our code to protect against that.

If you use invalid syntax and tear down the SA, then at least the
other end will know that they are doing something wrong and hopefully
they will fix their code at some point.

But I think correct option is to use exactly same protocol id than
what the initiator used, as that is what SA they are trying to use.

The Child SA is identified by the protocol id and spi tupple, so if
you do not have matching child sa, returning CHILD_SA_NOT_FOUND is the
correct, and as in the section 2.25 the RFC7296 says:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist.  The SA that the
   initiator attempted to rekey is indicated by the SPI field in the
   Notify payload, which is copied from the SPI field in the REKEY_SA
   notification.  A peer that receives a CHILD_SA_NOT_FOUND notification
   SHOULD silently delete the Child SA (if it still exists) and send a
   request to create a new Child SA from scratch (if the Child SA does
   not yet exist).

If the protocol id does not match the protocol id you are using, then
you do NOT HAVE matching Child SA, thus the other end is trying to
rekey sa that does not exists. 

I.e. the SPI field is copied from the REKEY_SA to CHILD_SA_NOT_FOUND
notify, then you needs to copy the protocol id too...

Also the section 3.10 of RFC7296 says:

   o  Protocol ID (1 octet) - If this notification concerns an existing
  SA whose SPI is given in the SPI field, this field indicates the
  type of that SA.  For notifications concerning Child SAs, this
  field MUST contain either (2) to indicate AH or (3) to indicate
  ESP.  Of the notifications defined in this document, the SPI is
  included only with INVALID_SELECTORS, REKEY_SA, and
  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
  sent as zero and MUST be ignored on receipt.

thus the Protocol ID field indicates the protocol id for the SA
indicated by the SPI field, thus Protocol ID and SPI are always going
together, and as REKEY_SA and CHILD_SA_NOT_FOUND are those few ones
that have Protocol ID and SPI non-zero you need to copy them.

You could submit an errata saying that

The SA that the
   initiator attempted to rekey is indicated by the SPI field in the
   Notify payload, which is copied from the SPI field in the REKEY_SA
   notification.

should say

The SA that the initiator attempted to rekey is
   indicated by the Protocol ID and SPI fields in the Notify payload,
   which are copied from the Protocol ID and SPI fields in the REKEY_SA
   notification.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?

[Tero Kivinen]

Tobias Brunner writes:
> > The SA that the initiator attempted to rekey is
> >indicated by the Protocol ID and SPI fields in the Notify payload,
> >which are copied from the Protocol ID and SPI fields in the REKEY_SA
> >notification.
> 
> Hm, I just noticed that we (strongSwan) implement that incorrectly as we
> send the CHILD_SA_NOT_FOUND notify without SPI (or protocol ID).  What's
> the purpose of repeating that information in the notify?  There can only
> be a single REKEY_SA notify in the request, so how could there be any
> confusion for the exchange initiator about which SA wasn't found by the
> responder?

I do not think there is any real purpose, but the cases where you need
to return CHILD_SA_NOT_FOUND usually means something unexpected
happened, and repeating the information might be helpful for debugging
that case.

The text was added in the draft-ietf-ipsecme-ikev2bis-07 when creating
RFC5996 (January 2010), and has not been changed since...
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?

[Tero Kivinen]

Andrew Cagney writes:
> > Also the section 3.10 of RFC7296 says:
> >
> >   o  Protocol ID (1 octet) - If this notification concerns an existing
> >  SA whose SPI is given in the SPI field, this field indicates the
> >  type of that SA.  For notifications concerning Child SAs, this
> >  field MUST contain either (2) to indicate AH or (3) to indicate
> >  ESP.  Of the notifications defined in this document, the SPI is
> >  included only with INVALID_SELECTORS, REKEY_SA, and
> >  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
> >  sent as zero and MUST be ignored on receipt.
> 
> I assume we're not discussing 0 or 1(IKE).  Which should be dismissed with
>INVALID_SYNTAX7
>Indicates the IKE message that was received was invalid because
>some type, length, or value was out of range or because the
>request was rejected for policy reasons.

REKEY_SA is only used when rekeying Child SAs, i.e., it is NOT used
when rekeying IKE SA.

> I like the principal.  As things go forward and exchanges for new
> protocols are defined they each get to spell out the details of things
> like the proposal sub payload
> and how to extract the Child's identifying material from the REKEY_SA.
> 
> Several things trouble me:
> 
> The first is that the RFC only defines how to extract the child's
> identifier for ESP and AH vis:
> 
>o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
>   IPsec protocol ID or zero if no SPI is applicable.  For a
>   notification concerning the IKE SA, the SPI Size MUST be zero and
>   the field must be empty.
> 
> which means that for a completely unknown protocol I'm left assuming
> the notify body is ESP/AH like (is SPI length = 8 reasonable?  Is SPI
> length = 0 with a 32k blob reasonable?).
> (I understand one implementation sends back an empty child-not-found
> notify, which at least avoids the need to parse the body).

If someone proposed to rekey protocol id that the receiving end does
not support, it means the other end is broken and is not following the
RFC. There is no way there could be and unknown protocol id already
negotiated between the peers if this peer does not recognize the
protocol id.

So either option is correct, either return CHILD_SA_NOT_FOUND and copy
protocol id, spi size, and spi from the REKEY_SA, or return
INVALID_SYNTAX and tear down the IKE SA.

Receiving unknown protocol id in rekey sa is clearly a bug in the
other ends implementation so it does not really matter what you are
doing, the other end should fix their code...

> The second is that the peer is trying to rekey a Child SA that can
> never exist.  Any attempt to establish this new unknown protocol
> should have failed as the proposal sub-payload containing the unknown
> protocol would be ignored.  I view that as pretty broken, or worse.

Yes. 

> Hence, when the protocol is completely unknown I se invalid-syntax as
> being an equally valid response.

In some implementations I know the policy of what protocol ids were
known and what kind of SPIs they are using was passed to the policy
module, i.e., the IKE module would never return that protocol id would
not be valid, as it did not know which protocol ids are valid and
which are not. The policy module was doing that checking. In such
cases it would be logical to the policy module to return
CHILD_SA_NOT_FOUND error. Note, that the policy module could be
dynamically loaded, and there could have been support for such
protocol id earlier (for example before reboot and updating the
system). 

If the policy module and IKE is tightly integrated, meaning that IKE
will immediately known that this protocol id cannot exists, thus it
can return INVALID_SYNTAX if it feels like it.

We usually do not mandate specific error codes to be used, as
different implementations can have different ways of checking things.
I.e. one implementation might do lookup based on protocol id + spi
without checking protocol id at all, and if no such match is found it
will return CHILD_SA_NOT_FOUND. Only after passing that it would start
looking actual value of the protocol id... 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IETF 117 agenda items

[Tero Kivinen]

Send requests for IETF 117 IPsecME agenda items to the
ipsecme-cha...@ietf.org by the end of this week, so I can create the
agenda for the IPsecME WG next week. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsecME WG Agenda for IETF 117

[Tero Kivinen]

It seems our agenda is already full. I would like to get slides for
all presentation during next week, i.e. before the 14th Friday
evening.
--
IP Security Maintenance and Extensions (IPsecME) WG.

IETF 117 - Wednesday July 28th, 2023 15:30-17:00 PDT
https://meetings.conf.meetecho.com/ietf117/?group=ipsecme&short=&item=1

Agenda

- Note Well, technical difficulties and agenda bashing - 
  Chairs (5 min)
- Document Status -
  Chairs (10 min)
- Other items
  - IKEv2 Optional SA&TS Payloads in Child Exchange (15 min)
Paul Wouters 
draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt
  - An RPKI and IPsec-based AS-to-AS Approach for
Source Address Validation (10 min)
Yangfei Guo 
draft-xu-ipsecme-risav
  - Traffic Selector for IKEv2 to add support DSCP (5 min)
Daniel Migault 
draft-mglt-ipsecme-ts-dscp
  - IKEv2 Link Maximum Atomic Packet and Packet Too Big
Notification Extension (5 min)
Daniel Migault 
draft-liu-ipsecme-ikev2-mtu-detect
  - Diet ESP: ESP Header compression, IKEv2 EHC (5 min)
Daniel Migault 
draft-mglt-ipsecme-ikev2-diet-esp-extension
draft-mglt-ipsecme-diet-esp
  - Anti-replay sequence number subspaces for traffic-engineered
paths and multi-core processing (10 min)
Pierre Pfister 
draft-ponchon-ipsecme-anti-replay-subspaces
  - Use of Reliable Transport in the IKEv2 (10 min)
Valery Smyslov 
draft-smyslov-ipsecme-ikev2-reliable-transport
  - Problem statements and uses cases for lightweight Child Security
Associations (10 min)
Steffen Klassert 
draft-mrossberg-ipsecme-multiple-sequence-counters
- Adoption calls (5 min)
  - draft-smslov-ipsecme-ikev2-qr-alt
  - draft-mglt-ipsecme-ts-dscp
  - draft-liu-ipsecme-ikev2-mtu-dect
  - draft-mglt-ipsecme-diet-esp
  - draft-mglt-ipsecme-ikev2-diet-esp-extension
  - draft-smyslov-ipsecme-ikev2-cookie-revised
- AOB + Open Mic (0 min)
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsecME WG Agenda for IETF 117

[Tero Kivinen]

Paul Wouters writes:
> On Jul 14, 2023, at 08:21, Tero Kivinen  wrote:
> > 
> > It seems our agenda is already full. I would like to get slides for
> > all presentation during next week, i.e. before the 14th Friday
> > evening.
> 
> I take it you mean July 21, and not today 😜

Yes, of course...
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsecME WG Agenda for IETF 117

[Tero Kivinen]

Tero Kivinen writes:
> It seems our agenda is already full. I would like to get slides for
> all presentation during next week, i.e. before the 14th Friday
> evening.

Updated version of the agenda, with some presentator changed:
--
IP Security Maintenance and Extensions (IPsecME) WG.

IETF 117 - Wednesday July 28th, 2023 15:30-17:00 PDT
https://meetings.conf.meetecho.com/ietf117/?group=ipsecme&short=&item=1

Agenda

- Note Well, technical difficulties and agenda bashing - 
  Chairs (5 min)
- Document Status -
  Chairs (10 min)
- Other items
  - IKEv2 Optional SA&TS Payloads in Child Exchange (15 min)
Paul Wouters 
draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt
  - An RPKI and IPsec-based AS-to-AS Approach for
Source Address Validation (10 min)
Ben Schwartz 
draft-xu-ipsecme-risav
  - Traffic Selector for IKEv2 to add support DSCP (5 min)
Daniel Migault 
draft-mglt-ipsecme-ts-dscp
  - IKEv2 Link Maximum Atomic Packet and Packet Too Big
Notification Extension (5 min)
Daniel Migault 
draft-liu-ipsecme-ikev2-mtu-detect
  - Diet ESP: ESP Header compression, IKEv2 EHC (5 min)
Daniel Migault 
draft-mglt-ipsecme-ikev2-diet-esp-extension
draft-mglt-ipsecme-diet-esp
  - Anti-replay sequence number subspaces for traffic-engineered
paths and multi-core processing (10 min)
Mohsin Shaikh 
draft-ponchon-ipsecme-anti-replay-subspaces
  - Use of Reliable Transport in the IKEv2 (10 min)
Valery Smyslov 
draft-smyslov-ipsecme-ikev2-reliable-transport
  - Problem statements and uses cases for lightweight Child Security
Associations (10 min)
Steffen Klassert 
draft-mrossberg-ipsecme-multiple-sequence-counters
- Adoption calls (5 min)
  - draft-smslov-ipsecme-ikev2-qr-alt
  - draft-mglt-ipsecme-ts-dscp
  - draft-liu-ipsecme-ikev2-mtu-dect
  - draft-mglt-ipsecme-diet-esp
  - draft-mglt-ipsecme-ikev2-diet-esp-extension
  - draft-smyslov-ipsecme-ikev2-cookie-revised
- AOB + Open Mic (0 min)
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

[Tero Kivinen]

Tobias Brunner writes:
> It already states in section 3:  "Non-optimized, regular rekey requests
> MUST always be accepted."
...
> So you're saying some configs, that are valid for regular IKEv2, will
> just not work with this extension?  And we'll only know once there is

Combining those two, I think this is fine. I.e., this is optimization
and it does NOT NEED to optimize every single possible configuration.
We can clearly state that if you are using certain configurations you
can't use this optimization, and have to fall back to normal rekey.

For example we could say that if you are negotiating multiple
protocols (AH + ESP or ESP + IPCOMP), or if you are using anything
else than one single KE algorithm for create child sa, you need to use
regular rekey.

> The only way to avoid that would be the extension either making
> childless IKE SAs mandatory, or strictly prohibiting inconsistent KE
> configs between IKE and Child SAs, taking away quite a bit of
> flexibility IKEv2 offers.

You do not need to make childless IKE SA mandatory, you simply need to
do first rekey after initial sa creation using normal rekey, and if
that normal rekey has SA/KE payloads that are acceptable for the
optimized rekey in the future, then you can use optimized rekeys in
the future. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-mglt-ipsecme-ts-dscp

[Tero Kivinen]

Daniel Migault writes:
> Let me know if that text addresses your concern or if you prefer a different
> wording. I believe I should add some more specific references to 4301. 

Note, that RFC4301 already describes how to handle DSCP, and your
draft would actually change mandatory features of RFC4301:

In section 4.1 Definition and Scope of RFC4301 says:

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature. Therefore, a sender
   SHOULD put traffic of different classes, but with the same selector
   values, on different SAs to support Quality of Service (QoS)
   appropriately. To permit this, the IPsec implementation MUST permit
   establishment and maintenance of multiple SAs between a given
   sender and receiver, with the same selectors. Distribution of
   traffic among these parallel SAs to support QoS is locally
   determined by the sender and is not negotiated by IKE. The receiver
   MUST process the packets from the different SAs without prejudice.
   These requirements apply to both transport and tunnel mode SAs. In
   the case of tunnel mode SAs, the DSCP values in question appear in
   the inner IP header. In transport mode, the DSCP value might change
   en route, but this should not cause problems with respect to IPsec
   processing since the value is not employed for SA selection and
   MUST NOT be checked as part of SA/packet validation. However, if
   significant re-ordering of packets occurs in an SA, e.g., as a
   result of changes to DSCP values en route, this may trigger packet
   discarding by a receiver due to application of the anti-replay
   mechanism.

I.e., it already says senders SHOULD use different SAs, and MUST
permit SAs with same selectors, and MUST process from each SA in same
way.


In section 4.4.1.2 Structure of an SPD Entry of RFC4301:

- Bypass DSCP (T/F) or map to unprotected DSCP values
  (array) if needed to restrict bypass of DSCP values
  -- applicable to tunnel mode SAs

I.e., SPD has option to specify whether DSCP is copied from inner to
outer or whether it is mapped using mapping array.

In section 4.4.2.1 Data Items in the SAD of RFC4301:

o DSCP values -- the set of DSCP values allowed for packets
  carried over this SA. If no values are specified, no
  DSCP-specific filtering is applied. If one or more values are
  specified, these are used to select one SA among several that
  match the traffic selectors for an outbound packet. Note that
  these values are NOT checked against inbound traffic arriving on
  the SA.

o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
  needed to restrict bypass of DSCP values -- applicable to tunnel
  mode SAs. This feature maps DSCP values from an inner header to
  values in an outer header, e.g., to address covert channel
  signaling concerns.

describes that each SAD entry already has an entry telling which DSCP
values are allowed for this SA, i.e., the sender will sue this item to
put packets with given DSCP values to speific SA, but it also says
that receiver does NOT check those values. 

> And another concern. I think that this document tries to
> improperly use existing mechanism. Traffic selectors negotiated
> in IKE SA are part of IPsec access control mechanism - i.e. they
> are used to cryptographically separate different types of
> traffic (ftp, http, etc.) and to allow performing access control
> (based on network characteristics). In my understanding, DSCP
> doesn't specify any particular kind of traffic, so it's strange
> to me to separate traffic based on its value.
>
> That said, I seem to understand the problem that you are trying
> to solve (correct me if I'm wrong): you want to make sure that
> if peer A uses SA1 for, say, high priority traffic, then peer B
> also use this SA (and not, say, SA2) for high priority traffic.
>
> If this is the problem, then perhaps it's easier to just
> introduce a new notify that will inform peer that this SA is
> intended to be used for some traffic priority. If peer supports
> this extension, it is supposed to also use this SA for this kind
> of traffic (it if honors this proposal). So, move from strict
> negotiation to just announcing.
> 
> I think you are correct in what we are trying to achieve. 

Reading the text below, I think you are trying to more than just keep
same DSCP values for both directions. 

> First let me state that we are open to alternate design. 
> 
> The issue with the notification is that there is no check on the
> inbound SA.

Re: [IPsec] draft-mglt-ipsecme-ts-dscp

[Tero Kivinen]

Daniel Migault writes:
> I am under the impression that if one wants to ensure that the agreed DSCP
> value takes the right SA we need to check that. As a result, I am inclined to
> have in any case a MUST be checked. I am wondering if we are expecting this
> check to take a significant overhead ?

I do not think there should be any need to check that agreed on DSCP
values takes right SA.

As the issue is that packets get dropped because of the replay window
checks, then it does not matter which SA they use as long as the
packets do not get dropped.

The sender has incentive to send them in best possible SA to make sure
they do not get dropped, but even that does not guarantee that someone
in the network does not decide to process the packets differently by
for example modifying the outer DSCP values in some way.

> I do not see a major change between using TS and a Notify. In both
> cases if the ts_dscp or the notify is not sent or not supported we
> fall back to the old case. So I do not expect that ts_dscp updates
> 4301 (maybe I am wrong). As a result, I am wondering what are the
> advantages of using a notification as opposed to a TS ?

There is big difference using traffic selectors and notify. First of
all that traffic selector would need special handling and coding in
the implementations to be understood at all. Old implementations would
at best return traffic selector set which do not include that new
traffic selector. On the other hand implementations might not be that
well written to handle unexpected traffic selectors. This was fine
with labeled ipsec as there it is assumed that both ends know that
both ends will support new traffic selectors. I would not be
suprised to find out that some implementations would NOT do that
narrowing properly when presented new traffic selector type, and
instead would return some fatal error. 

All current implemetations of the IKEv2 already knows that they need
ignore all unknown status notifications thus old implementations
getting DSCP notify would simply ignre it and the SA would be created
fine. 

> I do not see any and I am wondering if there are other reasons than
> that DSCP is not commonly used for access control. I have the
> impression this will be implemented the same way. In any case, if
> that is the reason I am wondering if we should restrict the draft to
> DSCP or consider that in the future additional parameters can be
> added or do we want to limiit it to DSCP ?     

DSCP is not access control it is giving hints to the router what type
of traffic is going through and what kind of QoS processing that type
of traffic might need.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsec Errata items

[Tero Kivinen]

Checking on the errata items for the old IPsec WG I found these three:

https://www.rfc-editor.org/errata/eid6953

This is against RFC2402 and the change is correct, there is
wrong section reference 3.3.2 where it should b section 3.3.3.

This should be marked as verified.

https://www.rfc-editor.org/errata/eid7244

This is for RFC3526 and it says that Generator should not be
2, but this is incorrect. The group in the RFC is generated
using the instructions frm the RFC2412 and that explains that
number 2 is not technically a generator, but there are reasons
to use it (APPENDIX E The Well-Known Groups of 2412):

   Using 2 as a generator is efficient for some modular
  exponentiation algorithms. [Note that 2 is technically not a
  generator in the number theory sense, because it omits half of
  the possible residues mod P. From a cryptographic viewpoint,
  this is a virtue.]

This change would be break interoperability with old
implementations and should be rejected.

https://www.rfc-editor.org/errata/eid4709

This is for RFC4301 and tries to fix the ASN.1 in Appendix C.
The proposed changes uses lines which are not part of the
RFC4301, i.e., the "=" -> "::=" that are listed as needed to
be done, are already in the RFC4301. Only other changes it
does is to remove "-- DEFINED BY algorithm" from one location,
but leave it in in few other places. It also chanegs the
iso(1) org (3) dod (6)" to "iso(1) identified-organization (3)
dod (6) which might be correct, but is not needed.

I think this errata should be rejected.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsecME errata items

[Tero Kivinen]

We seem to have 3 open errata for IPsecME WG documents:

https://www.rfc-editor.org/errata/eid6940

For IKEv2 RFC7296 changing "the field must be empty" -> "the
SPI field must be empty" in the SPI Size field description in
section 3.10 (the errata only says section ".10", when it
should have been "3.10").

This errata should be marked as Verified.

https://www.rfc-editor.org/errata/eid6339

This complains that "Curve25519 and Curve448 for IKEv2" RFC
8051, has Appendix A public keys for X25519 generated
incorrectly. I am not able to verify this as I do not have
code to verify the generated test vectors. If someone has code
that can verify the test vectors, please do so and report
here.

https://www.rfc-editor.org/errata/eid6931

This note that was split out from the previous errata for
RFC8031, is not really an errata but a comment for future
revision RFC 8031. I think we could simply mark it as Held for
document update, and solve the issue when someone decides to
update RFC8031.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPSECKEY errata item

[Tero Kivinen]

There is one errata item for IPSECKEY WG:

https://www.rfc-editor.org/errata/eid7402

This errata correctly identifies that the algorithm fields is
8-bit field, not 7-bit field as shown in the figure. The
section 5 IANA considerations of IPsec Keying Material in DNS
RFC4025 already explain that:

   This document creates an IANA registry for the algorithm type
   field. Values 0, 1, and 2 are defined in Section 2.4. Algorithm
   numbers 3 through 255 can be assigned by IETF Consensus (see RFC
   2434 [5]).

I.e., explains that the algorithm field is indeed 8-bit field.

This errata should be marked as verified.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

[Tero Kivinen]

Antony Antony writes:
> Thanks Lorenzo for this ID.
> I believe this is a great idea. Perhaps we could consider allowing a 
> non-zero ESP payload size? This would facilitate correlating responses upon 
> arrival at the sender. Then I would add an ESP message, format similar to 
> ICMP message. For instance, incorporating an identifier, like ICMP ping has, 
> would enable initiating multiple ESP pings from the same client and 
> receiving corresponding responses without mixing them up.

I think we should use normal ESP format i.e. have ESP SPI using
following format:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Security Parameters Index (SPI) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Sequence Number  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Payload Data* (variable)   |
  ~   ~
  |   |
  +   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   | Padding (0-255 bytes) |
  +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |  Pad Length   | Next Header   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Integrity Check Value-ICV   (variable)|
  ~   ~
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where SPI = 0x0007/0x0008

Sequence number is just 32-bit sequence number (always present, can
be used when correlating request to response).

Payload data/padding is can be any length in reqeust and is always
copied in response, i.e., it can be used as nonce/cookie to make sure
nobody out side the path can fake responses.

There would not be padding or next header fields, and the ICV field
would be zero length.

The final payload would look:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Security Parameters Index (SPI) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Sequence Number  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Payload Data* (variable)   |
  ~   ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

[Tero Kivinen]

Michael Richardson writes:
> 
> Tero Kivinen  wrote:
> > I think we should use normal ESP format i.e. have ESP SPI using
> > following format:
> 
> I mostly agree.
> But:
> 
> > (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
> 
> It would be nice to be able to put enough padding to make packets at least
> 1280, ideally 2048 bytes in size.
> 
> that would let us diagnose MTU issues better.

That (0-255 bytes) is leftover from the figure I copied from the
RFC4303, where it was part of the length of the padding field. In my
case I did assume that payload can be of any length, so I agree on
your fix...
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway)

[Tero Kivinen]

Yaron Sheffer writes:
> It seems to me we are splitting hairs here: what is the different
> between "hard expiry" and a hint? The protocol as it is today can
> handle the case when the gateway doesn't like the ticket it
> receives. And any reasonable client implementation will never send a
> stale ticket, regardless if this is "expiry" or a "hint". So the
> behavior is really the same. 

Hard expiry means that when it expires then client cannot use the
ticket anymore, which means it will most likely need to get new ticket
before this happens. I.e. client needs to have timer that will expire
before the ticket expires, and do INFORMATIONAL exchange with
N(TICKET_OPAQUE) and server replies to that with N(TICKET_OPAQUE).

This means that there is yet another thing we need to keep up and
running all the time we have IKE SA set up. So I do not want to have
protocol which does following:

 InitiatorResponder
 ---  ---
HDR, SAi1, KEi, Ni  -->

<--HDR, SAr1, KEr, Nr, [CERTREQ]

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
<--HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_OPAQUE lifetime=600)
[,N(TICKET_GATEWAY_LIST)]}

HDR, SK {N(TICKET_REQUEST)} -->
<--HDR, SK {N(TICKET_OPAQUE lifetime=600)
[,N(TICKET_GATEWAY_LIST)]}

HDR, SK {N(TICKET_REQUEST)} -->
<--HDR, SK {N(TICKET_OPAQUE lifetime=600)
[,N(TICKET_GATEWAY_LIST)]}

HDR, SK {N(TICKET_REQUEST)} -->
<--HDR, SK {N(TICKET_OPAQUE lifetime=600)
[,N(TICKET_GATEWAY_LIST)]}

HDR, SK {N(TICKET_REQUEST)} -->
<--HDR, SK {N(TICKET_OPAQUE lifetime=600)
[,N(TICKET_GATEWAY_LIST)]}
 

I would much prefer following protocol:

 InitiatorResponder
 ---  ---
HDR, SAi1, KEi, Ni  -->

<--HDR, SAr1, KEr, Nr, [CERTREQ]

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
<--HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_OPAQUE)
[,N(TICKET_GATEWAY_LIST)]}



<--HDR, SK {N(TICKET_OPAQUE)
[,N(TICKET_GATEWAY_LIST)]}
HDR, SK {} -->

I.e. during normal operations the tickets are just there. The client
stores the last ticket it has received from the gateway, and tries it
always if it has one when it needs to reconnect. If server does
something that will cause old tickets to expire it will send new ones.
This usually happens for example when the IKE SA is rekeyed or when
the encryption key used to encrypt the tickets is changed.

In this case there is no need for any lifetime parameters in the
tickets, or any periodic timers to get new ticket etc.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway)

[Tero Kivinen]

Tschofenig, Hannes (NSN - FI/Espoo) writes:
> We reused the same payload format for both directions. I added text that
> the lifetime in the C->S direction is set to the lifetime previously
> received. 
> 
> Alternatively, I could also introduce an additional payload format and
> exclude the lifetime. 
> 
> Do you prefer the latter? 

I would prefer to remove lifetime completely. I.e. keep the same
payload format for both uses, but do not include lifetime at all.

> >Also what does server does if the lifetime client gives when 
> >it presents ticket is different than what was sent before. Is 
> >that fatal error? Is that silently ignored? 
> 
> The draft says: 
> "
>The four
>octet lifetime field contains the number of seconds until the ticket
>expires (encoded as an unsigned integer).
> "

This does not tell anything whether client is allowed or not allowed
to mess around with the lifetime field of the ticket. It is clear that
if client modifies the ticket data the ticket will not work, but can
it for example send lifetime as zero when it is sending it to the
server at IKE_SESSON_RESUME. For example implementation which only
stores the ticket data, and sets timer to expire before the lifetime
expires (to get request ticket), might not need to store the original
lifetime value at all.

So I can see such implementation sending different values in the
lifetime field than what was originally sent. I can also see some
server implementations which might consider it an error if not same
value is not sent.

Thus if lifetimes are left in to the draft, then it either needs to
say that lifetime is ignored in the IKE_SESSON_RESUME when client
presents the ticket, or it needs to say that client must keep the same
value that was sent to it.

> >Another problem with lifetimes is that they do have explicit 
> >policy limits, meaning they will cause negotiations to fail. 
> >This happened a lot in the IKEv1 environment, and in the end 
> >it was always mandatory to make sure that both client and 
> >server used EXACTLY same lifetimes, as otherwise you most 
> >likely didn't interop.
> 
> Not an issue here as absolute time isn't used. 

I do not think absolute time has anything to do with this. In IKEv1
the lifetimes were presented in the same way as in your draft, and
there was lots of problems with them, i.e. other end rejecting the
exchange because the lifetime given in the exchange wasn't something
it was willing to accept.

> >This will mean that if client is configured for minimal 
> >lifetime of ticket of 3600 seconds, and server offers ticket 
> >which have lifetime of 3599 seconds, client will fail the 
> >negotiation. On the other hand if we say that there MUST NOT 
> >be any policy limitation checks for the lifetimes, then there 
> >is no point of tell them really, as server can simply start 
> >new INFORMATIONAL exchange and send new N(TICKET_OPAQUE) when 
> >the previous one is about to expire.
> 
> We can certainly add text to the draft discussing such a case. 
> If the client is not happy with what it gets then it can always start a
> full exchange. I don't see a problem with that. This is also a policy
> issue. In this specific case this is appropriate for the client todo. 

It can only do full exchange after the IKE SA has been deleted, but
for most of the time the IKE SA will still be there for long time.
I.e. when the IKE SA is first created and the ticket is given a 600
second lifetime, then during the 8 hours of working the ticket needs
to be requested again 48 times, and then when IKE SA goes away, then
10 minutes after that both server and client will know that ticket is
no longer valid. 

> Having tickets with a very short lifetime is probably not such a good
> idea.

But for loaded server it might want to use short lifetime, just so
that it does not need to store too much data for too long time, for no
real benefit.

Lets take example of big www-server protected by IPsec using
resumption. The web server might have million users connecting to it
every day, and each user usually requests a page (and the images on
it) and then reads for it for 5 minutes, and then gets next page and
so on for 30 minutes or so and then comes again next day (lets say
this is some newpaper or similar).

For this usage the lifetime of the ticket on the server end would most
likely be short, around 30 min - 60 min, as if client is away for more
than an hour, then it usually means it comes back only next day. If
server uses tickets by reference, meaning that the server stores the
actual ticket data (0.5 kB each), then storing tickets for all million
users would require 488 MB of storage space.

Storing tickets for those 100 000 users that come every hour requires
48 MB. If the server only tries to recover for cases where user
connection is lost for less than 10 minutes (i.e. it expires tickets
10 minutes after last packet has been received from the user), then it
only needs to store 8 MB of tickets. 

Is the sess

[IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Dragan Grebovich writes:
> Hi Tero
> I reviewed your heuristics draft and I believe it is interesting and
> doable, however:
> 
> 1) I believe the actual implementation would require more code than
> current front-end hardware allows.  The hardware we work with have a
> limited space for that much heuristics code.   Our preference is to find
> a quick direct match (in a few instructions max).  We would have to
> respin hardware to allow your heuristics implementation.  This might not
> be implementable today, as hardware respins are costly and take
> relatively long.

In normal cases, I would expect that heuristics are not run on the
hardware, only the SPI cache is run there (i.e. the Appendix A.1 part
of the operations). This kind of processing is already run on the
firewalls, deep inspection devices and so on, usually per TCP flow
basis. Adding that to be run on per IPsec SA basis should be very
small addition to the front-end hardware.

Are you saying that even that is too complicated?

> 2) On low-end products, e.g. Access (aka Edge) it is unlikely that
> today's and even tomorrow's implementations will have stateful DPI
> implemented; these devices have low target COGS and usually do not have
> simple packet filters and stateless firewalls and signature-based DPI
> and IDS/IPS.  It is unlikely that this would be the potential
> implementation target for heuristics, as the cost/price would go up.

If they do not have "simple packet filters and stateless firewalls and
signature-based DPI and IDS/IPS", then they do not need heuristics at
all, as there is no need to differentiate the ESP vs ESP-NULL.

Heuristics solution do not require any changes to those low-end
product. On the other hand the new protocol number for ESP most likely
will require changes to those devices, as they need to be sure to pass
that protocol number also.

> 3) High-end products, e.g. Data Center front-ends, would allow a
> heuristics implementation; it may have a stateful firewall and/or
> IDS/IPS and other DPI capabilities, however this class of devices is
> migrating towards virtualized platforms (major vendors are moving in
> that direction), and they would be terminating tens or even hundreds of
> thousands of SAs.

Heuristics are not needed on the devices which are terminating IPsec
SAs. Devices terminating IPsec SAs already know all IPsec SA state,
thus they do not need heuristics.

Heuristics is only needed on devices which do all the following:

1) Do want to some kind of deep inspection on the ESP-NULL packets.

2) Are on the path of the IPsec flow, but not participating in the
   IPsec SA (i.e. is not a node where IPsec SA terminates).

Note, that usually one IPsec SA has tens or hundreds of the TCP or UDP
flows inside, thus for each entry added to the SPI cache, the TCP or
UDP caches require much more. This means that high-end producsts need
to have memory for storing hundreds of thousands or even millions of
TCP/UDP flows anyways, and adding some for IPsec SA flows does not
significantly increase the number (in the worst case scenario, where
each IPsec SA has exactly one TCP flow inside, it might double the
number of flows needed to be stored). 

> 4) Even if these high-end devices have implementations running on
> multicores, everyone is struggling to provide low latency and high
> throughput, squeezing the last possible bit through of the pipe.
> Keeping state until one finds that there is a match or not may introduce
> unwanted latency and create large memory consumption (multiply
> everything by e.g. 100K Sas) which we may not be able to afford.

During normal operation there is no increased latency or slow
throughput, as the used IPsec SAs are already in the SPI flow cache,
and the parameters are fetched from there.

Even if there is hundreds of tousands of SAs, the rate of new IPsec
SAs created per second is very low. I.e. if IPsec SAs has lifetime of
1 hour, that means that every second we create on average of ~30 new
IPsec SA flows to keep up 100 000 IPsec SA flows running. Thus the
actual heuristics processing only requires to process around that
amount of flows.

Of course during the monday morning problem the rate will be higher,
but even so the heuristics is cheaper than the Diffie-Hellman required
to actually create those IPsec SAs, so even low powered CPU should be
able to easily to run heuristics on thousands or tens of thousands
packets per second.

After the heuristics is run then the processing is moved to the actual
fast path which only inspects the IPsec SPI flow cache and the src/dst
addresses and SPI number found from the packet.

> 5) On these High-end appliances, there is a definite need for
> load-balancing between flows.  That means the amount of the required
> memory space will be at least 2x or 3x more, and also there is need for
> additional CPU and I/O overhead to maintain two or more loanbalancers in
> sync.

Heuristics can be run separetely on each devices without any problems,
but the 

Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH

[Tero Kivinen]

Yaron Sheffer writes:
> Apologies for repeating myself. At the point when the client
> receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's
> going to receive a Redirect "right away". So the reasonable thing
> for it to do is to tear down the IKE SA immediately - the SA has
> just become useless. 

It should not tear down the IKE SA immediately, it should have short
delay there before doing that.

That kind of delay is also needed in case NO_ADDITIONAL_SAS is used
for other reasons, as if that is not used, then client will busy loop
creating new IKE_SA with IKE_SA_INIT, IKE_AUTH, INFORMATIONAL exchange
deleting the IKE SA, and then starting immediately from the
IKE_SA_INIT.

If there is short timeout (10 seconds or so) between IKE_AUTH and the
INFORMATIONAL exchange containing the delete payload deleting the IKE
SA then this will not be busy loop doing Diffie-Hellman, but slower
rate loop. The short timeout will also give server time to reply.
Note, that server can send reply immediately it does not need to wait
anything, i.e the INFORMATIONAL message telling client to redirect can
be send just immediately after sending IKE_AUTH reply.

Also client MUST still process incoming exchange while it is waiting
for the reply to the its delete, thus it will most likely get the
redirect message during that even if it issued delete immediately.

> In other words, we have a race condition between this notification
> (and the client's response to it) and the Redirect notification. And
> the simple solution is to send both notifications together.

Which means client code needs to understand that redirect notification
can come also during the IKE_AUTH, and depending on the IKE_AUTH use
of EAP, multiple auth etc things that requires modifications to the
existing complicated code.

So while adding support for the redirect in the client, it would be
good also be quite easy thing to ensure it does not delete the IKE SA
immediately, but wait for some time before deleting IKE SA.

I really do not want to make the most complicated exchange (IKE_AUTH)
even more complicated.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Grewal, Ken writes:
> The 'bait and switch' attack where a connection uses ESP-NULL and
> then at a later stage uses ESP-Encrypted may also be possible
> unintentionally. E.g. Connection to a server (cluster / farm) to
> gain access to a 'normal' service uses ESP-NULL and then at a later
> stage, where the previous connection was torn down and a new one
> built, the connection is obtaining some sensitive data and is now
> using ESP-Encrypted. On the outside, the connection attributes look
> the same (same server IP, same client IP (but may be different
> client due to NAT), same SPI - SPIs can be reused for new
> connections to preserve fast lookups algorithms at recipients), but
> underneath the connection is to access a different resource (may be
> using a different port or service above the IP layer). If the
> intermediate device has a cached rule (based on the previous
> connection) indicating the traffic is clear, it will lead to falsely
> inferring the contents of the payload and undesirable results.

This was covered in the draft section 7, where it said that if deep
inspection engine suddenly starts getting lots of garbage then it
should rerun the heuristics.

> I agree with Yoav that this attack may also be possible
> intentionally between two colluding parties, where the policy
> indicates all traffic is ESP-NULL. 

It is much easier to use ESP-NULL wrapped TLS, or SSH in those cases.
If both ends want to use encryption then the middle boxes cannot
really prevent it very easily. If TLS and SSH and blocked then use
IP(sec) over DNS, or IP(sec) over HTTP, and if even those fail then
use IP(sec) over mail :-)
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Feedback on the interim session's format

[Tero Kivinen]

Yaron Sheffer writes:
> If you feel like going into detail, here are some things we would
> like to understand: is the voice+IM format sufficient, or is
> application sharing a Must?

I think voice + IM is sufficient, but slide sharing would have been
even better. Now it was sometimes bit hard to know what slide people
were talking about, and also when I was presenting, I noticed that it
was sometimes hard to remember to say that I moved to new slide.

The slide sharing could be something very simple also, and it might
have been better if all the slides have already been converted (or
submitted) as html pages in addition to pdf.

I do not know if there is any freely usable slide sharing systems, but
setting up some web page using ajax or similar to fetch new page when
presenter moves to next page, should not be too hard to make (it
should be so simple, that I expect someone has already done that, so
perhaps we should check :-)

> Can we live with push-to-talk?

Push-to-talk works well for normal discussion, but it was impossible
to use when giving presentation, which meant that I myself changed the
setting to voice activated microphone when I started my presentation,
and then changed back to push-to-talk when I finished. This is
something that should be instructed for the people giving
presentations (there were others having problems too).

> Were you able to follow the discussion clearly?

Sound quality was good, and we did have less background noise than
what I execpted. Most likely because everybody was instructed
beforehand to use push-to-talk.

The +20dB microphone boost is something that also needs to be added to
the documentation. 

> Were you able to participate effectively?

Yes.

> Did you encounter any major technical problems (e.g. one person's
> corporate firewall prevented him from joining)?

Our corporate firewall did block teamspeak ports, but as I knew about
this beforehand, I was able to get the firewall rules changed so that
the teamspeak could be used. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Grewal, Ken writes:
> Cache eviction - how will this work?
> We can keep adding SAs (based on heuristics), but how do we decide
> when a given SA is no longer needed? This compounds the issues with
> keeping state, as in the best case, cache eviction will likely be
> policy based. How is the policy determined and how do we
> differentiate between short and long lived SAs? As the SA cache will
> be of a finite size, this WILL lead to a cache thrash (add SA, evict
> SA, ...), causing further resource consumption.

This is actually quite good point, and it is also implementation
detail that do affect the performance.

How this can be solved depends quite heavily on the environment where
heuristics is used. If we are doing firewall that already keeps state
of all TCP/UDP flows, then it would be natural to weakly bind IPsec
SAs and TCP/UDP flows inside together. For example keep in track when
there is no more TCP/UDP flows using the IPsec SA (i.e. all the
TCP/UDP flows which used this SA before, have now been moved to new
IPsec SA), and after that you can most likely remove the IPsec SA
entry quite quickly.

Another, and probably more common implementation will be just some
simple LRU based mechanisms to reuse old IPsec SA entries. This kind
of things are usually already done for the UDP protocols. 

> How about dynamic route changes for already established SAs? The
> same problem will exist as the Monday morning problem, but without
> the diffie-hellman overhead. Because we are caching state on one
> device, a change in route where the packets take a different path
> will force the new device to 'relearn' all the cached info.

Yes, but heuristics is still fast operation, thus that should not be
problem. Bigger problem usually is that the deep inspection state is
lost too...

> High availability is another one to consider, especially during
> maintenance periods. One device is powered down and a backup device
> takes over. This is similar to route changes in principle, where the
> backup device will need to relearn all the state.

As here the heuristics is run on the same device which is running the
deep inspection, they do already require methods of transferring that
deep inspection state from one device to another, and moving the IPsec
SPI cache state at the same time should not be a problem. 

> Agree, but the heuristics engine may be heavily used as VOIP becomes
> prevalent, especially within the Enterprise. Lots and lots of UDP
> traffic that is short lived, which ties back to earlier points on
> cache maintenance and frequency of exercising the heuristics engine.

If we know anything about the contents of the UDP packet (i.e.
recognize that it is VOIP traffic), we can most likely do heuristics
based on the single packet. Even if there is only 32 bits of the known
data in the packet (lets say version number and magic cookie or
similar), then usually that is already enough for detecting the
parameters and the probability that random ESP-encrypted packet has
same content is less than 0.00024% (1/(2^32) * 100%).

So if VOIP traffic is heavily used then the heuristics most likely
will have special protocol detection code for it.

> Auditing / logging / sniffing / sampling are some examples of
> stateless devices that do require to peek in the packets. Probably
> lots more also, so look for others to provide examples...

As those do not affect the forwarding of the packet, then the
reliability requirements for them is much lower, meaning that they can
also work without storing any state, and running heuristics for per
packet basis. That of course do require implementing the heuristics on
the hardware if we are talking about gigabit links or faster. My guess
is that without any hardware support and only using software with
modern CPU you can probably process more than 100MBit/s, but most
likely not full 1GBit/s speed.

Of course if you are talking about very low cost appliances, then they
will not have modern CPUs, but on the other hand people do not
normally expect them to keep up with 1GBit/s speeds... 

> The speed of deployment may or may not be true. If the stars are
> aligned, then it could be deployed within one or two refresh cycles,
> which is about the same for heuristics in intermediaries devices.
> After all, only a handful of vendors own a large percentage of the
> market for OS / intermediary devices. Adoption is obviously based on
> customer pull/perceived usefulness.

The difference is that heuristics can be deployed within one or two
refresh cycles of the intermediate devices after customers start to
ask for it.

Modified ESP can be deployed within one or two refresh cycles of the
slowest vendor whose devices are used in the network.

Meaning that if the printer vendor used in the network does not update
their IPsec to support that modified ESP, then that modified ESP
cannot be used by intermediate devices.

> >Heuristics can also be implemented regardless of IKEv1 or IKEv2.
> >Modifying the

[IPsec] Draft minutes from the interim meeting

[Tero Kivinen]

> IKEv2-bis
> Issue #11: Clarify which traffic selectors to use in rekeying.
> Paul: [unclear]. Tero: if you have SAs that violate the new
> policy, you either delete them or you rekey. Prefers a rekey,
> even if this is narrowing the SA. Mostly useful for decorrelated
> policies, but people are not doing that yet [general agreement by
> silence]. Gives an example of a specific connection moving from
> one SA to another, which he says is a policy change that requires
> a rekey, but only if you're doing decorrelated policy.

The example I gave was that we have IPsec SA between two hosts (or
subnets) and then someone adds new SPD rule which has higher
precedence and which says that port 80 between those hosts should be
put on separate SA. This effectively creates hole to the old IPsec SA,
thus the old IPsec SA now covers traffic selectors which it should
not. 

> Paul: if no-one is doing decorrelated policies, then they
> wouldn't have thought of this issue. Tero: some user
> interfaces may eliminate the need to support this feature
> altogether.

There is three ways to do this:

1) Forbid overlapping selectors (i.e. make user interface so that you
   cannot enter overlapping traffic selectors, and require
   adminstrator to "decorrelate" traffic selectors manually).

2) Go through SPD entries in the precedence order and do not use any
   kind of caching. This requires linear scan through SPD for every
   single packet.

3) Do the decorrelation properly and then you can use effective
   datastuctures to find the correct SPD entry, i.e. no linear scan is
   needed as you know that there cannot be any overlapping SPD entries
   in the decorrelated policy.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Dragan Grebovich writes:
> I looked for some traffic stats in a real, large enterprise network and
> I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic.  The
> stats were measured on multiple places in the network, and multiple
> samples were taken over the past 6 weeks.  Also, there is a slow but
> consistent growth of UDP traffic over the past couple of years, pointing
> to a long term trend.

Can you provide information what kind of UDP traffic that was? I would
except DNS, and different voip protocols, but what else? 

> IMHO heuristics would require more frequent inspections than just the
> first few packets in a flow, and would require more heuristics rules on
> a per app basis, instead of relying on fixed TCP immutable fields.

For heuristics it is enough to do just to inspect first few packets.
After we have found out the parameters, then we just use them. The
deep inspection that is using the results of the heuristics (i.e. to
find the actual protocol data) will of course need to inspect every
packet.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Feedback on the interim session's format

[Tero Kivinen]

Grewal, Ken writes:
> If there are alternatives that would allow operation over 'well
> known' ports such as 80, then those would be preferable. 

As most of those voice systems do use UDP, even using well known port
80 does not help as it is only open for TCP traffic. Running voice
over tcp gets quite poor results, especially if your connection might
drop few packets. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Grewal, Ken writes:
> [Ken] This may be feasible for stateful devices, but does not work
> for stateless devices (QOS/Statistics/auditing functions). Even in
> stateful devices, it requires coupling between observation on flows
> and the associated heuristics cache engine, which creates an
> additional overhead.

As the draft says this is mostly meant for stateful devices, and that
has been the main goal for the document. The charter says:

"A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system ..."

I.e. the main goal was set to be on the devices doing deeper
inspection i.e. firewalls and intrusion detection systems.

At least my conclusion on the list when we discussed on the usage
cases were for that kind of stateful devices.

Are QOS and auditing devices really stateless?

I would expect QOS devices to have all kind of reservation systems and
so on and for those I would expect them to be keeping state?

For the auditing I have been using I have usually enabled auditing of
new connections, not all packets, thus all my auditing systems I have
set up have been keeping state. What kind of usage is completely
stateless auditing devices used for your example of 10Gbps links?

Statistics devices could even be stateless, but is that really
something we should aim for? I.e. to wait for 5-10 years before we can
use our stateless statistics devices, compared to use stateful
statistics devices for doing the thing this or next year. 


> [Ken] These require timestamps (or other ordering / metric based
> approaches) and monitoring to ensure the cache is up to date.

Stateful devices do already have all that.

> Furthermore, it may also provide opportunities for adversaries to
> use periodic replays to provide cache thrash and associated overhead
> in re-executing heuristics engines.

As far as I have understood we are still talking about the inside one
enterprice network, not internet as whole. If they do have untrusted
users inside (i.e. attackers), they should enable encryption, thus all
this is not really a point.

As ESP-NULL does not offer confidentiality it can only be used in
trusted environments, where the denial-of-service attacks against the
device in the middle should not be big problem. 

> I am not convinced that SW based solutions will scale 10Gbps
> solutions, let alone future 40/100Gbps bandwidth requirements,
> especially at these network 'choke' points, so a HW orientated
> solution may be desirable...which brings us back to
> cost/complexity...

Limits for software based heuristics are not really related to the
line speed, but number of new IPsec connections per second going
through the device.

The line speed do affect the HW based flow cache lookup (i.e. the
appendix A.1 fastpath part of the processing), but that is doable even
at 10Gbps speed, as it basically does same thing as normal stateful
firewall rules (i.e. fetch flow information based on IP address pair,
protocol and in this SPI number instead of port numbers).

> >As here the heuristics is run on the same device which is running the
> >deep inspection, they do already require methods of transferring that
> >deep inspection state from one device to another, and moving the IPsec
> >SPI cache state at the same time should not be a problem.
> 
> [Ken] But again, this is additional work, which can be avoided if we have no 
> state.

Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV
len and IV len) per flow more when you transfer the whole deep
inspection state from device to other (which might include whole TCP
transmission window, which is around 64kB or so), so the increase of
additional work is about 0.009% (actually it is normally even less, as
TCP state is per TCP flow, and usually one IPsec flow has multiple TCP
flows inside, but in this case I took the worst case scenario, where
each IPsec flow have exactly one TCP flow inside).

I do not really consider that to really be matter.

(Doing deep inspection on TCP streams usually do require
reconstructing TCP stream in fully including dropped and retransmitted
packets. Otherwise there are attacks where you only inspect packet
which never reaches the end node (attacker causes it to be dropped),
and the retransmission packet is different than the first packet and
if you let that pass to the end node, attacker managed to get
uninspected packet through. Solution is that you either do the
retransmissions from your internal data or you verify that
retransmissions sent by the original node contains same data than
original packet, both of them do require you keep the TCP transmission
window data. This text is here just to explain that doing deep
inspection (for IDS or IPS) on TCP stream is very costly operation and
heuristics do have minimal cost compared to them.)

> >> Auditing / logging / sniffing / sampling are some examples of
> >> stateless devices that do require to peek in the packets. Probably
> >> lots more al

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Grewal, Ken writes:
> [Ken] In some cases, the certainty must be 100%, otherwise there is
> no control. E.g. A new exploit has just been published for certain
> types of traffic - published vulnerability where a virus/worm can
> exploit a 'buffer overrun/stack overflow' condition for a given
> piece of software providing a given service, which subsequently
> allows a hijacker to take control of the machine/server. That
> service MUST be shut down to ensure that the vulnerability cannot be
> exploited and spread. This may or may not result in shut down of the
> server hosting the service, as you may want to allow remote
> patching, etc. Easiest way to do this is to block the port over
> which the vulnerability is being exploited.  

Which does not help if you allow any encrypted ESP traffic to the
host, as the attacker will then just use encrypted ESP to make the
attack. On the other hand if you do not allow any encrypted ESP
packets, you KNOW that all packets are ESP-NULL, which makes the
packet checks much easier even for stateless devices.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Grewal, Ken writes:
> >Are QOS and auditing devices really stateless?
> >
> >I would expect QOS devices to have all kind of reservation systems and
> >so on and for those I would expect them to be keeping state?
> 
> [Ken] QoS may be applied on the need of the underlying service. E.g.
> A static rule that indicates that I place voice traffic in a
> priority queue over data traffic may be sufficient as a basic
> stateless rule.

Note that you cannot do QoS without the co-operation of the sending
IPsec site. The sending IPsec node needs to put packets getting
separate QoS handling to separate SAs as otherwise the receiving IPsec
node will drop packets if they get out of the replay window.

Because of this there is no need to inspect the content of the ESP
packet, QoS must be done based on the IPsec SA, i.e. IP-addresses and
SPI number.

So for QoS there is no need to inspect the data inside the ESP-NULL
packet, as you cannot give different handling to different packets, as
if you do so, then those ESP-NULL packets getting slower path might
get dropped by the receiving IPsec node, as those packets getting
faster path have already moved replay window so that those slower
packets do not fit in to it anymore.

> [Ken] We have been through the deployment timeframe arguments before
> and it looks like we are going in circles here. It is speculative to
> say how long one solution will take to be adopted instead of
> another. This depends on a number of factors - e.g. some network
> appliance vendors have indicated that they will not employ
> heuristics in their network devices due the cost / complexity, but
> prefer a more deterministic approach, whereas others may be more
> willing to add this support and charge a premium for the appliances.

My guess is that regardless what we do, at least some middle box
vendors will implement heuristics in their high-end boxes, and after
one vendor supports it, others need to support it too to be able to
offer similar features than their competitors do. After a while even
more low-end devices will support it and soon most middle boxes do
support it. After that the requirements for supporting WESP will drop,
as middle-boxes work without it, so general support for it will stay
even lower.

But that is just my guess...

> [Ken] Why is DoS not a big problem, especially if we generate a new
> DoS opportunity on a new 'cache' in the network device?

DoS opportunities is a problem, but I do not think SPI cache will
create that much new opportunities. I.e. I claim that the SPI cache
can be implemented in such way that it does not offer any major DoS
opportunity. 

> BTW, insider threats are on the rise according to various public
> reports, so should not be discounted. This is one of the motivations
> of employing security, even within the Enterprise.

Yes, but I do not really think people are going to solve those using
ESP-NULL. I think they must move to encrypted ESP to provide
confidentiality also, and that makes the need for ESP-NULL visibility
even less.

For example most of the insider information (insider trading, leaking
trade secrets, espionage) problems cannot be solved by using ESP-NULL.

> [Ken] Perhaps there is a migration path consideration, where
> heuristics can offer interim benefits until a more deterministic
> solution is adopted. Adoption of either / both / neither will be
> ultimately based on numerous factors, including value, customer
> demand, etc.

This I agree and I have even tried to bring this up in my draft (see
last paragraph in the introduction section).
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying

[Tero Kivinen]

Keith Welter writes:
> RFC 4718 section 5.11.8.  Collisions with IKE_SA Rekeying says:
>The case where CHILD_SAs are being closed is even worse.  Our
>recommendation is that if a host receives a request to rekey the
>IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
>closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
>receives a request to close a CHILD_SA after it has started rekeying
>the IKE_SA, it should reply with an empty Informational response.
>This ensures that at least the other peer will eventually notice that
>the CHILD_SA is still in "half-closed" state and will start a new
>IKE_SA from scratch.
> 
> Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B 
> receives it.  What should host B do next?  Host B was attempting to rekey 
> the IKE SA and needs to retry that operation.  Is it acceptable for host B 
> to retransmit the CCSA request with the same message ID even though it has 
> received a response? 

If B retransmits the CCSA request with same message ID, then host A
will retransmit its NO_PROPOSAL_CHOSEN reply, so there is no point of
retransmitting old CCSA request with same message ID.

If IKE SA is in half-closed state and B does not know that yet, then
it means that A has already sent out delete notification for the IKE
SA, and then B sent CCSA before receiving that delete notification,
and that was the reason A replied with NO_PROPOSAL_CHOSEN. So B does
not really need to do anything, it should receive delete notification
very soon.

It can install timer (for example 60 seconds or so), and retry the
operation after that (or it can wait until the hard lifetime is
reached, and delete the old child SA then and then next packet will
trigger new child sa creation).

If it still fails, it knows there is something wrong with the
syncronization of the both ends, and in that case it should delete the
IKE SA and start from the scratch.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Is an empty CertRequest payload valid in IKEv2?

[Tero Kivinen]

David Wierbowski writes:
> If there is no concept of an empty certificate request in IKEv2 why is the
> text in section 3.6 a SHOULD and not a MUST?  It seems to me that in order
> to ensure interoperability the text in Section 3.6 should read,
> "Certificate payloads MUST be included in an exchange if certificates are
> available to the sender.  An encoding type of Hash and URL of X.509
> certificate or Hash and URL of X.509 bundle MAY be used if the peer has
> indicated an ability to retrieve this information using an
> HTTP_CERT_LOOKUP_SUPPORTED Notify payload."


There are good reasons not to send certificates in some cases. For
example if you use certificate infrastructure where you know each end
do have ability to fetch the certificates based on the ID (for example
there is LDAP/HTTP/DB access that all certificates users are using for
getting certificates), then it would not be beneficial to send
certificates every time you make IKE SA. In normal cases you SHOULD
send them (perhaps in HASH and URL form if that is supported). In some
cases you might know you do not need to so, so in that cases you can
ignore that SHOULD and not send them.

So the default for IKEv2 is the same as if in IKEv1 you had sent empty
certificate request. If you have certificates then you should send
them.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Bhatia, Manav (Manav) writes:
> > 
> > > BTW, insider threats are on the rise according to various public
> > > reports, so should not be discounted. This is one of the motivations
> > > of employing security, even within the Enterprise.
> > 
> > Yes, but I do not really think people are going to solve those using
> > ESP-NULL. I think they must move to encrypted ESP to provide
> > confidentiality also, and that makes the need for ESP-NULL visibility
> > even less.
> 
> I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors
> will implement ESP (besides the problem of AH being NAT unfriendly).
> All applications (OSPFv3, RIPng, etc), and there are many, which
> don't care about confidentiality, but are only concerned with
> authentication and integrity assurance, will continue using
> ESP-NULL.  
> 
> Thus there is a need for ESP-NULL visibility. 

What kind of deep inspection you are doing on the OSPFv3 and RIPng in
the middle boxes? I.e. why does middle boxes need to know anything
about the actual data contents of those protocols?

You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility
is needed. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying

[Tero Kivinen]

Keith Welter writes:
> Actually the IKE SA is open.  Host A sent NO_PROPOSAL_CHOSEN because it 
> received a request to rekey the IKE SA when it had a child SA in
> half-closed state. Here is the specific scenario I'm interested in:
> 1) Host A initiates rekey of a child SA.
> 2) Host B processing of CCSA request triggers rekey of IKE SA due to 
> local lifesize policy.
> 3) Host B sends CCSA response for child SA.
> 4) Host B sends CCSA request to rekey IKE SA.
> 5) Host A receives CCSA response for child SA.
> 6) Host A sends delete for prior child SA.
> 7) Host A receives CCSA request to rekey IKE SA but child SA is 
> half-closed.  Host A sends NO_PROPOSAL_CHOSEN in CCSA response.
> 8) Host B receives delete for prior child SA.  And responds with
> empty informational message since it is rekeying the IKE SA.
> 9) Host B receives CCSA response with NO_PROPOSAL_CHOSEN.
> 10) Host A receives empty informational message.

I think B should send delete for the old child SA immediately when the
IKE SA failed, i.e. when A replied with NO_PROPOSAL_CHOSEN, as after
that it is no longer rekeying IKE SA. When host A receives that the
old child SA has been deleted completely, and after that host B can
restart IKE SA rekey. 

> Should host A do something special when it receives the empty
> informational message?

Yes, it should mark down it has half-closed child SA, and if the
situation is not fixed in next few minutes, then it should delete
whole IKE SA and start over.

> Is there any reason why it shouldn't close it's child SA since it
> got a response?

It got response, but other end didn't close his end of the child SA.
It should wait for the other end to close down the child SA. If the
other end closes it, then it will return back to normal.

If other end does not close it in few minutes (say 5 minutes), then it
should delete IKE SA and start over. See section 1.4 of RFC4306:

   A node SHOULD regard half-closed connections as anomalous and audit
   their existence should they persist.  Note that this specification
   nowhere specifies time periods, so it is up to individual endpoints
   to decide how long to wait.  A node MAY refuse to accept incoming
   data on half-closed connections but MUST NOT unilaterally close them
   and reuse the SPIs.  If connection state becomes sufficiently messed
   up, a node MAY close the IKE_SA; doing so will implicitly close all
   SAs negotiated under it.  It can then rebuild the SAs it needs on a
   clean base under a new IKE_SA.

I.e. MUST NOT unilaterally close, and if state beecomse sufficiently
messed up, MAY close IKE SA.

> > It can install timer (for example 60 seconds or so), and retry the
> > operation after that (or it can wait until the hard lifetime is
> > reached, and delete the old child SA then and then next packet will
> > trigger new child sa creation).
> 
> Since this sort of retry isn't a retransmit I suppose an exponential
> back-off of any subsequent retries isn't required but might be nice.

I do not think there will be that many retries. If the second try
fails again, it usually means there is something messed up, so it
might be better to delete old IKE SA and start over as I said here:

> > If it still fails, it knows there is something wrong with the
> > syncronization of the both ends, and in that case it should delete the
> > IKE SA and start from the scratch.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

[Tero Kivinen]

Bhatia, Manav (Manav) writes:
> > You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility
> > is needed. 
> 
> One might want to filter OSPFv3 packets coming from outside the domain.

It is much better to do that check on the OSPFv3 receiver end where
the packet is actually authenticated by ESP-NULL, and which has much
better knowledge who is authorized to send what.

I do not know OSPFv3 that well, so I do not know how you tell which
packets are coiming outside of domain (as IP-addresses are not
authenticated in ESP-NULL, so those cannot be checked), so I cannot
really tell whether that check is doable or not.

So what are the exact checks you are doing and where inside the OSFPv3
packet content are those fields, and what do they gain compared of
doing the same checks on the final OSPFv3 receiver?

> Then when you're the end node, you might want to prioritize some
> OSPF packets over the others. I understand that the latter is an
> implementation specific issue, but it helps if the underlying
> protocol is amenable for deep inspection. 

End node already has all ESP-NULL related information, there is no
need for ESP-NULL visibility there.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Payload order in IKEv2 (tracker issues #16 and #45)

[Tero Kivinen]

Paul Hoffman writes:
> RFC 4306 says:
>Although new payload types may be added in the future and may appear
>interleaved with the fields defined in this specification,
>implementations MUST send the payloads defined in this specification
>in the order shown in the figures in section 2 and implementations
>SHOULD reject as invalid a message with those payloads in any other
>order.
> 
> a) Downgrade the MUST to a SHOULD without other changes.

I think that should be fine, but I think more important would be to
change "SHOULD reject" to "SHOULD NOT reject" or even "MUST NOT
reject". As I do not think anybody currently follows this SHOULD I
think that should not make any current real implementations
incompatible with new versions.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type

[Tero Kivinen]

Paul Hoffman writes:
> At 12:48 PM -0800 1/25/09, Paul Hoffman wrote:
> >Yes, definitely. At this point, we have heard from two groups of
> authors; hearing from the wider implementers community would be
> valuable. 
> 
> We still have not heard from many.
> 
> During the interim meeting, a good question was raised: are we
> making this decision based on implementation desires vs. protocol
> cleanliness vs. deployment ability. We don't have enough input at
> this point to pick between those. 
> 
> So, let me get this thread going again. If you have an opinion about
> the core issue of how session resumption is done (extend the
> IKE_SA_INIT or create a new exchange type), please state it again
> and say what draws you to this conclusion. This is *not* a vote: it
> is a request to get the discussion going with some hopefully better
> metrics. 

I suggest keeping it as separate new exchange type.

That should be cleaner from protocol point of view (keep separate
options separate, do not create master jumbo super hyper exchange
doing everything).

That should also be easier to implement as it can be added as modular
addition to the existing implementation, without breaking existing
functionality. 

The resulting code should be simplier than modifying already complex
code.

One of the things that do require modification of the existing code is
this exchange will change the very basic current practice of the
IKEv2, where the packet is either completely unencryptede or it is
completely encrypted. With this new exchange some payloads are in
clear and some are encrypted. This most likely will cause changes to
the packet parsing and encoding routines. This is not affected by the
fact whether we use separate exchange or change IKE_SA_INIT.

Note, that this text in the ticket is wrong: "More efficient protocol
of the responder *does not* implement this extension".

If the initiator has ticket then it KNOWS that responder do support
this extension (as otherwise responder would not have sent him
ticket). Using IKE_SA_INIT offers a bit more efficient protocol in
case the ticket initiator is using has already expired, and initiator
needs to fall back to full exchange.

If any IKE_SA_INIT packet containing any encrypted payloads is sent to
implementation which do not support this extensions, all those packets
will be silently ignored. This does not offer initiator an option to
try to use ticket with parties it does not know whether they support
this extension or not.

So for my point of view:

Using separate exchange is simplier, easier and cleaner way to do it.

Modifying IKE_SA_INIT optimizies very rare event when the ticket has
already been expired by the responder when initiator tries to use, and
saves one round trip times for those cases. The implementations will
be more complex, and will most likely contain more errors.

I do like the unix tools principle, i.e. make small tools (cat, grep,
head, tail etc) that do the work they are designed to and then combine
them for more complex things. Here I would like to have one more new
clean tool (new IKE_SESSION_RESUME exchange) instead of tweaking
existing tool (IKE_SA_INIT) to do yet another thing.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #22: simultaneous IKE SA rekeys

[Tero Kivinen]

Yoav Nir writes:
>  
> Hi all.
> 
> Section 2.8.1 of the draft discusses what to do when Child SAs are rekeyed 
> simultaneously by both peers. Issue #22 asks to clarify the same thing for 
> simultaneous rekeying of IKE SAs.
> 
> We've written a proposed additional section, that should be labeled 2.8.2. 
> Since this specifies new behavior that was not specified before, we want your 
> comments before putting this into the draft.
> 
> Thanks
> 
> Yoav
> 
> 
> 2.8.2.  Simultaneous IKE SA rekeying
> 
>If the two ends have the same key lifetime policies for IKE SAs, it
>is possible that both will initiate a rekeying at the same time.
>This is unacceptable for IKE SAs, because the IKE SAs own the child
 

It is not unacceptable to initiate rekeying at the same time. It can
and will happen. What is unacceptable is that we get two IKE SAs and
parties do not agree on which one is the one that should be used, and
to which one the Child SAs are moved to.

>SAs, and deleting the IKE SA leeds to deletion of all child SAs.  To
>reduce the probability of this happening, the timing of rekeying
>requests SHOULD be jittered (delayed by a random amount of time after
>the need for rekeying is noticed).
> 
>To avoid the case of two IKE SAs created by simultaneous
>CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the

Again we cannot avoid the case where they start CREATE_CHILD_SA
exchange simultaneously. We can only give rules how to solve this.

>initiator nonces is silently discarded, and the dependent child SAs
>are transferred only to the IKE SA with the higher of the two
>initiator nonces.  Here "higher" and "lower" refer to octet-by-octet,
>lexicographical comparison of the nonces as large integers.

This is completely unacceptable. Firstly it is not following the rules
already in the RFC4306 which cleary says that both IKE SAs are created
as normally, and then the one follow the rule: "the SA created with
the lowest of the four nonces used in the two exchanges SHOULD be
closed by the endpoint that created it."

With IKE SAs this just requires that both ends need to agree that
child SAs are always moved to the other IKE SA.

We already do implement this rule specified in the RFC4306 for IKE
SAs, we do not care about the simultaneous CHILD_SA/IPsec SA rekeys as
they do not really cause problems (there will be duplicate
CHILD_SAs/IPsec SAs but everything still works).

Anyways we cannot "silently discard" any IKE SA packets, IKE SA basic
principle is to provide request/reply exchages, thus there must be
reply, as otherwise the other end will tear down the IKE SA. 

>The rules are as follows:
>1.  If a rekey request is received before this host has sent a rekey
>request of its own, this host MUST NOT send a rekey request.
>Instead, it MUST reply to the rekey request it has received.
>2.  If a rekey request is received after this host has sent a rekey
>request, then this host MUST compare the two initiator nonce
>values.  If the received nonce is higher than its own, it MUST
>reply to the received request, and SHOULD stop retransmissions of
>its own request.  If the received nonce is lower, it MUST ignore
>the received request.
>3.  If a rekey request is received after this host has sent a rekey
>request, and the peer has already replied, the new received
>request MUST be ignored.

This will be major change to the existing RFC4306 behavior. Especially
is it violates the basic IKEv2 exchange principles. I thing doing this
is really bad idea.

It requires quite big changes to all over the code (i.e. ability to
get messages back from the retransmit and window processing queue),
and so on.

The current code we have already implemented, and which works (I only
use the example where all request packets from responder are lost for
duration of the initiators exchnage as that covers all possible
cases):

Host A   Host B
     
   # Start rekey # Start rekey
   HDR, SK{SA(SPIa1), Ni1, KEi1} --->

  X <--- HDR, SK{SA(SPIb2), Ni2, KEi2}
This is dropped

# B receives A's requst
# It knows there is simultaneous
# rekey, but it will not yet
# know A's reply nonce, so cannot
# do anything. It ties both
# rekeyed SAs together and to old IKE
# SA, and replies normaly
<--- HDR, SK{SA(SPIb1), Nr1, KEr1}

   # A receives B's reply, but it
   # still does not know there
   # is simultaneous rekey as
   # it has not seen B's
   # request yet.
   # It processes request
   # normally, creates new IKE SA1
   # and 

[IPsec] WESP questions

[Tero Kivinen]

Dan McDonald writes:
> Some quick/dirty WESP questions.
> 
> 1.) Can I use WESP with IKEv1 also?  I don't see why not, but maybe we are
> using WESP as an incentive to move people to IKEv2?

I do not see any point of standardizing anything to already obsoleted
protocol, so I would say IKEv2 only.

I also personally do not see any way I would be ever implementing WESP
negotiation to our IKEv1 library...

Also the current draft refers to RFC4303 (ESP) and RFC 4302 (AH) which
are for RFC4301 and IKEv2.

Also knowing how long it will take before this will be used widely, I
do not think limiting it to IKEv2 only is going to cause problems.  

> 2.) Is it permitted to use non-NULL encryption with WESP?  I'm hoping the
> answer is NO, but I didn't see any such language in the November 2008
> draft.

As the draft includes second unencrypted copy of the next header
field, I myself assumed it is not limited to ESP-NULL. If it is
limited to ESP NULL, then it would be better to only use one next
header field.

It also says the next header field in the WESP header might be zero
for "security concerns"...
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] questions on redirection during IKE_AUTH

[Tero Kivinen]

fan zhao writes:
> However, while receiving the NO_ADDITIONAL_SAS in the last IKE_AUTH
> (before the N(Redirect)
> is received), the IPsec client may try to connect with another IPsec
> gateway (it can select one from
> a list of gateways, for example, returned by the DNS response).
> Especially when during HO,
> the client wants to perserve its IP address/mobility states, it needs
> to do so since it knows
> that the connection with the current IPsec gateway is unsuccessful.
>
> Such the selected IPsec gateway may be different from the one that
> will be indicated in the N(REDIRECT).
> Therefore, when the client processes the N(Redirect), it may realize
> that it needs to abort
> the communication with another IPsec gateway, which results in overhead.

Client should wait for the few milliseconds it takes to get the next
packet immediately following the IKE_AUTH reply before trying to
connect new gateways. If client wants to waste resources by doing
guesses where it will be redirected then that is its problem.

So I do not consider that protocol issue but issue with bad
implementations wanting to waste resources. We cannot really solve all
bad implementation issues, vendors can always make bad implementations
which waste even more resources.

For example the client can start connecting to all gateways in the
beginning even before receiving any REDIRECT notification. We do not
have anything in the draft forbidding (or allowing) that either, and
I do not think we need to cover all possible ways people can make bad
implementations. 

> Furthermore, the current draft specifies that when the client receives
> N(redirect), it MUST send an empty
> message as an acknowledgement.

That requirement does not come from the redirect document, it comes
from the base IKEv2 specification, which mandates that each request
MUST receive reply.

The redirect document cannot really change the IKEv2 base document
requirements, thus all implementations implementing IKEv2 will already
require that same thing. 

> However, the current draft does not specify how to handle such
> cases.

The draft does not need to specify such things, as those are not
redirect specific cases, they are generic IKEv2 questions.

Base IKEv2 RFC already covers what do when packets are lost, and how
redirects are handled in that case.

The current IKEv2 RFC does not specifically tell how to handle the
ongoing exchanges when delete notification is sent.

It does say that delete payload deleting IKE SA must be last REQUEST
sent over an IKE SA (section 2.8). As the generic requirement for
IKEv2 exchange handling is that it MUST be able to process incoming
requests at any time (even when it has already send out delete request
himself, but not received reply for it yet), the node which have sent
delete request out, must still process all incoming notifications
(including N(REDIRECT)) until it receives reply to the delete
notification.

On the other hand the other end who has already started some other
exchange with the other node (for example who has sent N(REDIRECT)
request) might want to postpone replying to the delete notification
until it gets the reply for all ongoing requests it has sent out. In
most cases that does not matter, as deleting IKE SA will also delete
all data associated with it, thus it does not matter whether it waits
replies or not, as those replies can only affect things that will be
deleted when IKE SA is deleted, but REDIRECT notification also affects
future IKE SAs, thus it should not reply to the delete payload
deleting IKE SA until it has received reply for its N(REDIRECT)
request.

It can also include N(REDIRECT) in to the reply to be sent to delete
payload, as was explained already in the mailing list. The responder
will then get either of those N(REDIRECT) payloads (either the
original request, where it will then send reply, or the reply to the
delete payload deleting IKE SA, in which case there will not be any
other packets sent out (replies are only sent to request, replies are
never sent out for received replies).

This behavior is completely valid based on the RFC4306. The reply
received for the delete payload deleting IKE SA is just normal reply
message, thus it will still be processed as normally. For example the
section 5.8 for RFC 4718 says that normally there is no information
that needs to be sent to the other side, thus empty information
response is usually used, but in this case we do have information we
want to send, thus we can just put the N(REDIRECT) there to give that
information.

Note, that N(REDIRECT) notification payload DOES NOT require any
reply, thats why the normal reply message to the request containing
N(REDIRECT) will be empty message.

> One special case is that N(redirect) is lost and the client sends a
> delete request. And in this case, the gateway cannot piggyback the
> N(redirect) together with the delete payload. Because otherwise, the
> client cannot send back the empty message to the gateway.

Re: [IPsec] questions on redirection during IKE_AUTH

[Tero Kivinen]

fan zhao writes:
> > Client should wait for the few milliseconds it takes to get the next
> > packet immediately following the IKE_AUTH reply before trying to
> > connect new gateways. If client wants to waste resources by doing
> > guesses where it will be redirected then that is its problem.
> 
> RFC 4306 and IKEv2bis do not specify that "Client should wait for the
> few milliseconds it takes to get the next packet immediately following
> the IKE_AUTH reply before trying to connect new gateways."

RFC4306 does not specify that client MUST immediately close the IKE SA
down if it receives NO_ADDITIONAL_SAS during IKE_AUTH. RFC4306 does
not say anything about the matter.

> This sounds like a new requirement to me.

REDIRECT is new requirement, it does cause changes to the
implementations, and this is one of those changes, that if
implementation was written so it immediately deleted the IKE SA if
IKE_AUTH received NO_ADDITIONAL_SAS, then it would be better to change
it so it will instead wait for few seconds before deleting the IKE SA.

You cannot implement REDIRECT without making any changes to the
implementation.

Note, that REDIRECT will still work even if you do not wait. It is
just bad implementation to immediately delete the IKE SA at that
point, as it will most likely just cause busy loop consuming
resources.

I.e. if the other end happened to return NO_ADDITIONAL_SAS not because
of REDIRECT, but because it could not create new IPsec SAs even when
it could create IKE SAs. If client implementation immediately deletes
IKE SA and starts over, it will create busy loop doing Diffie-Hellmans
and authentication and creating new IKE SA as fast as it can, and then
delete it again if server still does not have any resources. Much
better implementation will add some timer there and will not try again
as fast as possible, but instead wait for few tens of seconds to allow
server to perhaps free up resources, or at least slow down the busy
loop. This does not have anything to do with redirect, it is just how
good implementation should behave in general.

> Furthermore, considering that the IPSec gateway sends the NO_ADDITIONAL_SAS
> not because of redirection, but because of be unwilling to accept the child
> SA, there is no point that the client needs to wait because the gateway
> will not send the N(Redirect) in this case. Also, when the N(redirect)

As I explained above it is better to wait even in that case, as
otherwise you just busy loop and create accidental denial of service
attack against the server.

> This issue is because the NO_ADDITIONAL_SAS is re-used during the IKE_AUTH
> in case of redirection, which results in overheads. The NO_ADDITIONAL_SAS
> originally is not defined for the redirection purpose.

NO_ADDITIONAL_SAS was defined to be used in cases where "responder is
unwilling to accept any more CHILD_SAs on this IKE_SA.". This is
exactly the case here in the REDIRECT case too. I.e. server does not
want to allow new CHILD_SAs on this IKE_SA as it knows it will
redirect the client away.

It is true that the description only mentioned CREATE_CHILD_SA
request, but in most cases the initial IPsec SA creation happening
during the IKE_AUTH is handled identically to the CREATE_CHILD_SA.
Exceptions where they receive special handling is listed specifically
(i.e. KEYMAT generation etc).

> The issue here is that when the client receives the
> N(NO_ADDITIONAL_SAS) and before receiving the N(Redirect), it
> decides to delete the IKE SA since such a SA is useless. When the
> gateway receives such delete request, it does not know whether the
> N(Redirect) has already been received.

It will know that it has not received reply to the N(REDIRECT). 

> Therefore, it cannot delete the IKE SA because if the N(redirect) is
> lost and the IKE SA is deleted, the gateway cannot re-transmit the
> N(redirect). This is the case specific to the redirection. It is
> possible for the gateway to include the N(redirect) in the reply to
> the delete request, please see below for more on this.
> 
> >
> > The current IKEv2 RFC does not specifically tell how to handle the
> > ongoing exchanges when delete notification is sent.
> Maybe because the scenario of redirection is not considered?

Not really. The reason it does not cover what happens to the exchange
during IKE SA rekey or when IKE SA is deleted, is that those details
were just omitted.

The delete case is not usually the problem, as when IKE SA is deleted,
there is nothing left, meaning there is no need to think what happens
to the ongoing exchanges. N(REDIRECT) changes this bit, as this notify
will not affect the IKE_SA, it will affect the client state outside
the IKE SA, thus it makes big conceptual change to the IKE SA. Thats
why the redirect draft needs to specify what happens if you have
ongoing N(REDIRECT) out and you receive delete notification for the
IKE SA.

The bigger generic problem is what happens to the ongoing exchanges
during IKE SA rekey.  This gets ver

[IPsec] Question on Authentication failure

[Tero Kivinen]

Raghunandan P (raghup) writes:
> During the IKEv2 negotiation, suppose an authentication failure occurs
> on the responder side, a Notify payload with AUTHENTICATION_FAILURE is
> sent in the AUTH_EXCH response back to the initiator (Message 4). Is
> this correct?

Yes. We do have open ticket for ikev2bis whether that notification
should be sent unencrypted or not. As we have not finished
authentication we cannot send it authenticated, but as we have
finished Diffie-Hellman we can send it encrypted and integrity
protected if we like. Sending it encrypted and integrity protected
does provide proof that the error was sent by the party who
participated in the Diffie-Hellman exchange in the IKE_SA_INIT, but it
does not provide proof that the party is actually the intended party
you tried to talk to (i.e. it could be man in the middle attacker).

See the 2nd part of the ticket #9 for the ikev2bis document and the
related ongoing discussion on the IPsec list. 

> Will there be any ACK sent from the initiator for this
> notification?

No. As that error will be sent as response to the request sent by the
initiator, there cannot be any response to response packet (section
3.1: "An IKE endpoint MUST NOT generate a response to a message that
is marked as being a response.").

> Suppose the authentication failure happens on the initiator (and not the
> responder), how is this handled? Does initiator send an explicit Notify
> to the responder, which needs to respond back with an ACK?

If the authentication failure happens on the initiator side, initiator
has two options.

1) It can simply silently delete the half-created IKE SA, and fail the
   connection attempt (for his point of view the IKE SA was never
   created, thus it is allowed to do that). Responder who thinks the
   IKE SA exchange was successful will keep the IKE SA up, and as
   there is no traffic at all over it, it will most likely trigger
   some dead peer detection query after some timeout, and as initiator
   does not have the IKE SA up, it will not reply to those, and after
   the timeout the responder will also delete the IKE SA because it
   failed dead peer detection.

2) It can finish creation of the IKE SA, but mark it as failed, then
   after that it can start new INFORMATIONAL exchange in the IKE SA
   and send request containing delete payload to the responder. When
   responder receives that it will delete the IKE SA and send empty
   response back (responder still needs to keep IKE SA alive for some
   timeout, in case the response was lost and initiator retransmits
   its request). When that response is received by initiator it will
   delete the IKE SA.

The second option has problems as it creates "unauthenticated" IKE SA
which could be used to attack the initiator unless the initiator is
protected by such by making sure that no exchanges can be done over
that IKE SA. This requires implementations to understand that this IKE
SA has special status of unauthenticated.

The first option on the other hand does not delete the IKE SA from the
responder, thus responder will still think the IKE SA is up and alive,
and will keep it there wasting resources until the dead peer detection
fails.

I think the most common case is to use the first option, as it does
not really require any extra code, and initiator end will still log
that connection failed, thus for example in remote access cases the
interactive user who initiated the connection will see that and can
change configuration etc to fix the situation. And as responder
already did manage to authenticate the initiator, this cannot be used
as unathenticated denial of service attack.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

[Tero Kivinen]

pasi.ero...@nokia.com writes:
> I have one somewhat substantial concern with the document: it needs to
> be much clearer about what information is updated by the received
> REDIRECT messages, and what is not.

Never really thought that issue. I myself assumed that both GWs are
identical, i.e. they return same ID, and use same authentication data
(i.e. if PSK, both use same PSK, if certs, both authenticate against
same trust anchor and use same identity in cert, but not necessarely
same private key).

> One possible answer would be that REDIRECT is interpreted just as data
> received from DNS, so all the gateways (redirecting among each other)
> would send same IDr value.

I think this is the easiest way to make sure redirect is secure.

> - Section 5: I don't think treating REDIRECT+"sufficient time period"
> as implicit delete is a good idea. RFC 4306 requires sending delete
> payloads whenever possible, and if the VPN GW wants to close the
> IKE_SA, it could include the Delete payload in the same message as the
> REDIRECT notification...

I think it said that it can delete it without client sending any
packets, but that delete is not implicit, it is explicit, and gateway
will then send delete payload to delete the IKE SA. The sufficient
time is used when the client has been talking to the gateway for
longer already, and has multiple IPsec SAs up and in use. Then when
gateway decides to redirect client somewhere else it sends N(REDIRECT)
and client acks that. After that client starts recreating existing IKE
SA and Child SAs with the new gateway, and after finishing that the
client will delete the IKE SA with delete payload. If server runs out
of resources before that it can send delete payload even before client
finishes its redirection process but as that causes disruption of the
flow of packets (if client didn't have time to set up new Child SAs),
server should allow some time for that.

I agree that the text could be written in more clear way, i.e.
explictly say that the "delete the securition association" does mean
the normal IKEv2 way, i.e. sending delete payload. 

> - Section 7: I'm a bit skeptical if this actually works. The rest of
> the document certainly does not describe how it would work, and in
> many places, assumes the client-gateway case (e.g. Section 6.1 says
> REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the
> responder can't actually tell the initiator it supports this feature,
> etc.) Also, the "what is actually updated by REDIRECT and what is not"
> may get even more complex in peer-to-peer case.  My personal
> preference would be to restrict the scope to client-gateway unless
> someone really has the energy needed to specify how the peer-to-peer
> case works in detail.

Also the current text says

"the responder MUST NOT respond to re-direct message from the
initiator, if it has already decided to re-direct the initiator."

and that is impossible with IKEv2. If node receives some request, it
must reply with response, it cannot leave that response out, as if he
does that then the IKE SA will be teared down when the other end times
out the exchange.

I think the original idea was that even when we talk about VPN client
and gateway, this could be used as building block for other things
too, and even this document uses terms like "VPN client" and "VPN
gateway", this could also be used even when the IKE peers are not VPN
client/gateway. This includes cases where for example SIP/MobileIP
client connects to SIP/MobileIP server using IPsec.

I do not think this can be used as generic gateway to gateway
redirection mechinism (MOBIKE can be used for that too). 

I.e. I would simply change the section 7. to contain:
--
7.  Use of the Redirect Mechanism between IKEv2 Peers

   The Re-direct mechanism described in this document is mainly intended
   for use in client-gateway scenarios.  However, the mechanism can also
   be used between any two IKEv2 peers, but this protocol is
   asymmetric, meaning that only the responder can redirect initiator
   to some other server.
--

And leave everything else out, including changing the protocol so it
can be used in both directions. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #42: Improve example of multiple proposals

[Tero Kivinen]

Yaron Sheffer writes:
> Yaron: a new proposal example would be appreciated!

I provide replacement text at in the thread starting at 2008-09-23
15:52 (message id <18648.59003.22895.803...@fireball.kivinen.iki.fi>).

here is link to the thread: http://thread.gmane.org/gmane.ietf.ipsec/8317
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

[Tero Kivinen]

Vijay Devarapalli writes:
> The draft currently requires the client to delete the SA once it
> receives the REDIRECT message from the gateway. I do not want the
> gateway to delete the SA right away. The gateway should allow the
> client to setup the necessary security associations with the new
> gateway before deleting the SA with the existing gateway, if that is
> what the client wants to do. The current text is to handle the case
> where for some reason the gateway does not receive the DELETE payload
> from the client. Note that this shouldn't happen normally. The gateway
> garbage collects the SA after a certain time period. I don't think the
> gateway needs to send a DELETE payload at this point.

I disagree with that. If gateway decides to delete the IKE SA, it
needs to send DELETE payload in that case. The only case where you do
not send DELETE payload is when you delete the IKE SA because some
exchange over the IKE SA timed out (i.e. other end didn't respond). In
that timeout case there is no point of sending DELETE payload, as most
likely that will not reach the other end any better than the original
exchange, thus it will also timeout.

In this redirect case the client might just be slow, or it might be
that the gateway where client was redirected to does not respond, and
client does not delete the old IKE SA before it gets new one up and
running. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

[Tero Kivinen]

Yaron Sheffer writes:
> I have a slight preference to keeping the protocol symmetric. But
> even if we choose not to do that, I think Tero's text (quoted below)
> leaves too much room for interpretation.

Redirect is not really symmetric ever. If it would be used in
symmetric way, then each end would simply create the connection using
the address they want whenever they want. I.e. if server wanted to
redirect client to somewhere else later, it would simply inform that
new gateway to make connection to the client and close the local
connection. That new gateway would then simply initiate new connection
to the client and move traffic to there.

The reason we cannot do that is that client-server connections are
very often asymmetric, i.e. we are using EAP, or client is behind NAT
or similar problems. 

> 7.  Use of the Redirect Mechanism between IKEv2 Peers
> 
>The Re-direct mechanism described in this document is mainly intended
>for use in client-gateway scenarios.  However, the mechanism can also
>be used between any two IKEv2 peers, but this protocol is
>asymmetric, meaning that only the responder can redirect initiator
>to some other server.
> ---
> 
> The protocol supports using an Informational exchange for redirect
> at any time during the SA lifetime, and this is inherently
> symmetric.

No, it does not make it symmetric. If the original initiator wants to
use other local address when connecting, he will simply switch to that
new address and initiate new connection. Original responder cannot do
that, as most likely the connection using new address does not work
because of NATs or because of asymmetric authentication type used
(EAP).

> And of course, following an IKE SA rekey, the
> initiator/responder roles might change. If we go for the restricted
> option, the new text should cover both of these issues.

I should have used "original responder" and "original initiator".
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

[Tero Kivinen]

Yaron Sheffer writes:
> I am thinking of symmetric IKE peers (gateways, or endpoints using
> transport mode ESP; no EAP, rarely any NAT). Is there any reason why
> the current draft cannot support this case in a symmetric manner? 

Why do you need any protocol for that. Why does not normal IKEv2 be
enough for that.

I.e. if node A wants the node B to move to use some other location, it
can simply connect to node B using that new location, and remove the
old IKE SA.

I.e. if scenario is really symmetric, there is no need to have any
IKEv2 redirect protocol at all, everything can be done by the node by
directly connecting using new location.

It is quite hard to explain this thing as I have no idea what kind of
scenario you are talking about. Can you give real example, what the
nodes are and why do they want to redirect other end.

MOBIKE is not restricted to the VPN client <-> VPN server situation,
but is limited that node must stay same. I.e. it is moving between
multiple addresses of node A and moving between multiple address of
node B. It cannot ask node B to move from node A to node C.

But if node A wants node B to use node C instead of node A, it can
simply inform node C to make connection to B and delete its own IKE
SA. It can also do this by just changing the back end routing or
similar, so that return packets go to node C instead of node A and
then node C will initiate connection to node B immediately when first
packet arrives (if the situation is really symmetric).

If we are talking about client and server situations where server
wants to redirect client to some other server, then situation is no
longer symmetric.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Query on IKEv2 SA

[Tero Kivinen]

Raghunandan P (raghup) writes:
> IKEv2 protocol supports continous channel mode, which implies that once
> we delete IKEv2 SA, all the IPSec SAs created using this IKEv2 SA also
> get deleted. However, if the last IPSec SA is deleted, the IKEv2 SA is
> not deleted. Is this understanding correct?

Yes, that is correct. You can have IKE SA without any Child/IPsec SAs. 

> If the above is correct, what is the purpose of having this standalong
> IKEv2 SA? Since maintaining the IKEv2 SA consumes resources in the
> system, what is the advantage offered by having this standalong IKEv2
> SA?

Lets say you have situation where you create new Child/IPsec SA for
each TCP connection. With for example web traffic those TCP
connections are quite short lived, and it would be very expensive to
create new IKE SA for each of them, so you want to create them using
same IKE SA. When the last TCP connection goes away (and user is
reading the web page), the IKE SA will still be kept there, and then
when user clicks some link to fetch more stuff from the server, new
TCP connections are created, and those can be created using the
already existing IKE SA.

So in some scenarios it is advantageous to keep the IKEv2 SA up even
after the last Child/IPsec SA disappears. In some scenarios it might
be useful to put some kind of idle timer there, and delete that IKEv2
SA if it stays there for too long (for example more than 10-30
minutes).

> If the standalone IKEv2 is indeed brought up, when is this IKEv2 SA
> deleted and what is the method used to delete this IKEv2 SA? One example
> is a phase 2 proposal mismatch, in which case, we can still bring up the
> IKEv2 SA only. How is the IKEv2 SA deleted in this case and in any other
> general case?

IKEv2 SAs are only deleted by two ways:

1) Explicit INFORMATIONAL exchange having delete payload in request
   packet (with Protocol ID 1 for IKE_SA, and empty SPI), and other
   ends response packet (without delete payload, so this response is
   usually just empty packet (i.e only encrypted payload but nothing
   in there).

2) By timeout, i.e. if other end does not send response to the request
   that has been "retransmitted at least a dozen times over a period
   of at least several minutes before giving up on an SA". In that
   case the IKE SA is simply remoeved from memory, without further
   communcations to the other end.

Note, that case 1 applies also to the old IKE SA after IKE SA rekey,
i.e. even that will be deleted by sending delete payload in
INFORMATIONAL exchange. 

> I could not find much information on this in the draft and hence more
> clarity would help.

Case 1 is explained in section 3.11 of RFC 4306 and section 5.8 of
RFC4718. Case 2 is explained in section 2.4 of RFC 4306.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04)

[Tero Kivinen]

Vijay Devarapalli writes:
> There at least three people who think that the IKE_AUTH response
> message should itself contain the REDIRECT payload. I went through the
> email exchange between Fan and Tero.  There was no new information
> that came out of that discussion for me to make this change in the
> draft.
> 
> Does any one else have an opinion?
> 
> Otherwise I suggest the WG chairs to make a call on this.
> 
> Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response
> 2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a
> REDIRECT message, would work.

If you add text allowing REDIRECT with IKE_AUTH, then add also text
explaining how REDIRECT is used with other different extensions,
including EAP and multi auth. I.e. what happens if the server returns
REDIRECT before the first EAP exchange is finished, or what happens if
the server returns REDIRECT after the first EAP has succeeded, but
before the AUTH payload exchange after that, or what happens if server
returns REDIRECT even when the client wants to do another AUTH
negotiation etc.

I.e. if we take following example from the RFC4739:

  Initiator   Responder
 --- ---
  1. HDR, SA, KE, Ni -->
 <--  2. HDR, SA, KE, Nr, [CERTREQ],
  N(MULTIPLE_AUTH_SUPPORTED)
  3. HDR, SK { IDi, [CERTREQ+], [IDr],
   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
 <--  4. HDR, SK { IDr, [CERT+], AUTH,
   EAP(Request) }
  5. HDR, SK { EAP(Response) }  -->
 <--  6. HDR, SK { EAP(Request) }
  7. HDR, SK { EAP(Response) }  -->
 <--  8. HDR, SK { EAP(Success) }
  9. HDR, SK { AUTH,
   N(ANOTHER_AUTH_FOLLOWS) }  -->
 <--  10. HDR, SK { AUTH }
  11. HDR, SK { IDi }  -->
 <--  12. HDR, SK { EAP(Request) }
  13. HDR, SK { EAP(Response) }  -->
 <--  14. HDR, SK { EAP(Request) }
  15. HDR, SK { EAP(Response) }  -->
 <--  16. HDR, SK { EAP(Success) }
  17. HDR, SK { AUTH }  -->
 <--  18. HDR, SK { AUTH, SA, TSi, TSr }

In which packets is the REDIRECT allowed. Is it only allowed in the
final 18th message? Is it also allowed in packet 10? Can it be sent
during any time of the EAP exachanges?

This is actually something that is bit unclear already in the RFC4306.

For notification payloads belonging to the IPsec SA (IPCOMP_SUPPORTED,
ADDITIONAL_TS_POSSIBLE, USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO), it is quite
logical that the payloads containing SA and TS* payloads are the ones
where they should be in, but for example ESP_TFC_PADDING_NOT_SUPPORTED
and NON_FIRST_FRAGMENTS_ALSO do not contain explicit text listing
where they should be.

For others there are other defined places (i.e.
HTTP_CERT_LOOKUP_SUPPORTED should be in the payload containing
CERTREQ, REKEY_SA should be same packet as SA payload, COOKIE and
NAT_DETECTION_*_IP are used only in IKE_SA_INIT).

For status notifications like INITIAL_CONTACT and SET_WINDOW_SIZE there
is no defined or logical place to send them, so most likely they can
be in any packet during IKE_AUTH exchange (or after that as separate
INFORMATIONAL exchange).

The RFC4478 defines one more status notification i.e. AUTH_LIFETIME
and that is defined to be in last IKE_AUTH message, or as separate
INFORMATIONAL exchange.

MOBIKE (RFC 4555) defines that the new status notifications which can
be in IKE_AUTH (MOBIKE_SUPPORTED and ADDITIONAL_IP*_ADDRESSES) are in
the IKE_AUTH message containing the SA payload.

I assume that REDIRECT is going to be status notification, which means
that the IKE SA is created even when that is returned during IKE_AUTH,
and then the resulting IKE_AUTH still needs to be deleted with
separate INFORMATIONAL exchange containing delete payloads.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #17: Checking of the other peer's IKE SPI

[Tero Kivinen]

pasi.ero...@nokia.com writes:
> Yaron and Tero,
> 
> Hmm... it seems changing your own IKE SPI during an IKE_SA does not
> work anyway, so if you get a packet where the peer's SPI is different
> (than what it used for this IKE_SA earlier), it did not come from 
> a spec-compliant peer.
>  
> The question is whether we should require the recipient to check
> that the peer's SPI has not changed. To me, it looks like this would
> not be an interoperability issue (the peer is doing something outside
> the spec, so it can't expect any particular behavior from us)... 
>  
> Tero, how did you encounter this in the interops? (And was the node
> sending this buggy, or did it consider itself to be behaving according
> to the spec?)

The sender was TAHI project IKEv2 tester, and if I remember correctly
they sent that on purpose and they expected the other end to detect
that SPI changed, and not to continue because of that. Our code simply
used our own SPI as that is sufficient to find the IKE SA and we
didn't really care what was in the other ends SPI. I did add
additional check to our code to check the other ends SPI and drop the
packet if it is changed. 

> If it's not an interop issue, and not a security issue, then I'm
> not sure if mandating such check is needed. But are there some 
> security implications?

I agree that there is no real need to mandate such check, but if
IKEv2 tester implementations are requiring such check that will be
de-facto requirement to add such check, as otherwise you will not pass
their tests.

So for that it is interoperability issue, as you cannot pass their
interoperability tests if you do not check it. So thats why I think it
would be good to say that either it is valid to check only your own
SPI or that you MUST check both spis. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04)

[Tero Kivinen]

Vijay Devarapalli writes:
> The one significant piece of information that the gateway has during the 
> IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, 
> is the identity of the client. Some folks want to redirect the client 
> based on whatever identity it presents. So if thats they case, the first 
> IKE_AUTH response would be used for sending the REDIRECT payload. If the 
> gateway wanted to redirect the client because of load conditions, it 
> would have done it during the IKE_SA_INIT exchange itself. I don't 
> expect the EAP exchange or the multiple auth exchange to trigger a 
> redirect. We can make this explicit if needed.

I tought someone wanted to do some kind of radius lookup to select
where client is redirected to and in some cases client might not be
sending the ID used for that in the ID payload but might use the EAP
identity request/reply (even though RFC4306 3.16 says SHOULD NOT).

If it will be enough to only see IDi to do redirect, meaning we can
always restrict the REDIRECT to message 4, then it might be even
acceptable to make that change. The main reason I was against having
REDIRECTS in IKE_AUTHs is that there is so many locations where it can
be and testing all possible combinations with all possible
authentication methods and other extensions gets very complicated.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

[Tero Kivinen]

Paul Hoffman writes:
> >I think the REDIRECT mechanism is of limited use if you can only
> >redirect to another gateway for which the mobile node already has a
> >PAD entry. 
> 
> Hmm. That was not clear to me from the document, but I could have
> missed it. What do others think about this statement? 

I didn't get that from the draft. The current draft does not mention
anything about PAD, and doing dynamic updates to PAD (or SPD) is
something that must be explicitly mentioned if such things are
supposed to happen, as they have lots of security implications
(overwriting existing rules, to which location dynamic rules are added
in the ordered PAD/SPD, what information is exactly put there).

On the other hand I do not think the REDIRECT mechanism will be that
much in limited use, even if the PAD entries must be configured.

The mobile node requires PAD entry for the first gateway anyways, and
if that PAD entry identifies the group of peers instead that one peer,
and provides authentication data for each peer (for example say that
they are authenticated using certificates signed by CA X).

Depending on the configuration this can still be done quite easily.
Example could be that PAD define ID must be *.sgw.example.com. and the
peer must authenticate itself using certificate signed by CA X. Then
first gateway can provide ID sgw1.sgw.example.com and it can redirect
client to server, which then will use ID sgw2.sgw.example.com, and
that will still match the same PAD entry. Both gateways will use
certificates provided by the same CA so their authentication
information is same.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

[Tero Kivinen]

Yaron Sheffer writes:
> The exact same thing applies to the gateway-to-gateway situation. Suppose
> Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into
> maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just
> initiate a connection to D, because it doesn't know that it needs to until
> told by GW C. And it doesn't matter who initiated the SA in the first place.

When C goes to the maintenance, it will also change routing so that
packets which used to come to him, will go to D. Immediately when
first such packet gets to D, the D will initiate connection to A, so C
can simply change the routing, and then delete all IKE SAs. 

> Yes, there is some routing/tunneling magic going on "behind" the gateways,
> but why should we rely on it to initiate the IKE redirection, when we have
> the mechanism defined in the current draft?

Mostly because redirections gets very complicated if both ends can
move at will... For example what happens if the gateway A is rebooted,
while C is still down. Now C will not reply with redirect to D, thus
we still need to rely on some other external mechanism to redirect
stuff from C to D, i.e. most likely both of them are configured in the
configuration, so A will know that it can connect either C or D.

When we were writing MOBIKE, we noticed that things gets very
complicated very quickly if such scenarios are allowed, and in that
case you cannot really expect the systems to just work, you still need
to write new document profiling how nodes should be configured and
used in such cases.

If we are going to need such profile anyways to get usable protocol,
we can write protocol extension at the same time which profiles
redirect to be used in gw-gw scenarios and also extends and defines
how it should be used in that case.

We have way too many protocols already where the actual protocol
document does not provide interoperability. The documents are so wide
open, that nobody implements all the optional things (or not even all
the mandatory to implement things), thus you cannot just take two
implementations and assume they work together on your specific
scenario. In those cases you need to write profile that tells what
features are required, and then you might get interoperability
(provided you will find any implementations fulfilling those
requirements).

My proposal was to say that we do not define that usage in this
document, but it is not explicitly forbidden either, so we assume that
if such usage is needed, new document extending this one will be written.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04)

[Tero Kivinen]

Vijay Devarapalli writes:
> My proposal is to limit the REDIRECT payload to appear in message #4 (in
> the first IKE_AUTH response), based on the identity presented by the
> client. And leave EAP scenarios out of scope for this document.

If others feel this is needed, I am willing to accept that solution,
as it should still be fixed defined location, which means testing it
will be simplier. 

> If someone wants the AAA server to redirect the client based on the
> EAP exchange, a separate document could be written. And this
> document can specify that the REDIRECT message can be sent in
> message 10.

In this case I would rather propose doing the IKE AUTH exchange
completely and then using the INFORMATIONAL exchange to redirect the
client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the
first response IKE_AUTH packet of the exchage, and nowhere else.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04)

[Tero Kivinen]

Vijay Devarapalli writes:
> Agree. Here is the text proposal to address this issue.
> 
> If the gateway decides to redirect the client during the IKE_AUTH
> exchange, based on the identity presented by the client in the
> IKE_AUTH request message, it prevents the creation of a CHILD SA and
> sends the REDIRECT payload in the IKE_AUTH response.  When the client
> receives the IKE_AUTH response with the REDIRECT payload, it MUST
> send an empty message as an acknowledgement and delete the IKEv2 SA
> as described above.

That empty message as an acknowledgement is completely against the
generic IKEv2 exchange model. That is unacceptable.

Also the text does not say whether the IKE SA creation succeded or
failed when REDIRECT was sent. As REDIRECT is status notification it
would indicate that IKE SA succeded, and in your example it must have
succeeded, as initiator used it after the IKE_AUTH to send that empty
message.

I think the correct way to do that is to split REDIRECT to two
different notifications, one REDIRECT that is allocated from the
NOTIFY MESSAGES - ERROR TYPES range (0-8191) which indicates that the
IKE SA creation failed and initiator MUST move to new location. This
is the one that should be used in the IKE_SA_INIT and IKE_AUTH phase.
Then there would be another status REDIRECT, which is allocated from
the NOTIFY MESSAGES - STATUS TYPES. This status REDIRECT would be used
in the INFORMATIONAL exchanges, i.e. where it does not cause IKE SA to
be deleted when such notify message is received.

This whole discussion is putting more and more me back to my original
opinion that we should NOT allow redirects during IKE_AUTH.

There is reason to do the redirect during IKE_SA_INIT before doing
Diffie-Hellman.

There is reason to do it after kwowing the identity, but as others has
pointed out in that case it should be done only after the identity has
been proven. If redirection is done only after identity has been
proven, then it can be done as separate INFORMATIONAL exchange after
the IKE_AUTH.

I do not want REDIRECT to be defined so that it can be sent any time
during IKE_AUTH as that exponentially multiple the number of test
cases required for IKE_AUTH tests (i.e. test REDIRECT during all the
possible half a dozen messages using different authentication methods
including multiple authentication etc). 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DoS Attack Possibility?

[Tero Kivinen]

Vijay Devarapalli writes:
> Sounds ok to me. Anyone else have comments/opinions on this before I add 
> this to the document?
> 
> We can have a random 32-bit identifier included in the 
> REDIRECTION_SUPPORTED payload and have the gateway echo this in the 
> REDIRECT payload. Note that this would be applicable only to redirect 
> during the IKE_SA_INIT exchange.

32-bits is way too short. If you want cookie better use something that
is suitable for cookie, and even better do not limit the size. As
there is no data currently in the REDIRECT_SUPPORTED, better to just
say that the whole REDIRECT_SUPPORTED payload must be returned as is
by the server when it is sending REDIRECT back. You can use similar
text RFC4306 has about nonces, saying that they must be t least 128
bits in size, and must be randomly chosen (i.e. the length MUST be
between 16 and 256 octects inclusive). 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DoS Attack Possibility?

[Tero Kivinen]

Yaron Sheffer writes:
> I'm not sure in what way this is worse than other potential attacks at this
> stage, such as sending back an unprotected notification saying that the
> offered group is unacceptable.

If attacker sends notification back saying the offered group is
unacceptable, it will also indicate new group (which must be part of
initiators offer) in the notification payload, and then initiator
tries again with that. If that new group is acceptable by the server
too, then they create IKE_SA with that group, and as it was acceptable
with both it is ok. It might not be the strongest group they
supported, but the group is one of the acceptable groups for both
ends.

For other unauthenticated error emssages the initiator should ignore
them, and keep trying until the exchange times out.

> This case is different though if the attacker redirects into a legitimate
> gateway, because things look normal, traffic gets through, but an innocent
> gateway may get overwhelmed if all other "equivalent" gateways are
> redirected to it.

Yes. 

> It may be simpler to echo the nonce Ni back to the initiator as part of the
> Redirect payload. This would introduce no new state.

That would also be good solution, as the nonce is already defined to
be random and large enough. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Ticket #9

[Tero Kivinen]

David Wierbowski writes:
> Ticket #9 says"If the authentication fails in such ways that the entries
> cannot create IKE SA (authentication failure or similar), then the response
> will be unencrypted, unauthenticated notify."  Back in January there was
> additional discussion about this issue.  Several people supported sending
> the response as an encrypted, authenticated notify.  The reason being that
^
> the only entity who can send an encrypted, authenticated notify is the
> person with knowledge of  SK_e* and SK_a*.

That authenticated is very dangerous word there. The party sending
that notification is NOT authenticated. He has not proven his
identity by sending AUTH payload. As this error happens BEFORE he
sends that payload, the notification will never be authenticated in
the IKEv2 sense. It will be integrity protected, and they are known to
be come from the same UNAUTHENTICATED party who responded to the
IKE_SA_INIT exchange and did Diffie-Hellman.

Man in the middle attacker can trivially fake that message, and if the
receiving party actually takes them as authenticated error messages
from the party he intended to talk to, he might do actions based on
the attackers notifications.

I agree there is benefit for allowing those encrypted and integrity
protected notifications, as they do prove that they are sent by the
same party who responded to the IKE_SA_INIT, thus they do tell that
there is no point of continue that IKEv2 SA creation. On the other
hand those cannot be taken as really authenticate errors, thus the
initiator should still delete that partial IKEv2 SA attempt and try
again (perhaps after suitable timeout).

As it seems to be hard thing to distinguish for even here in the IPsec
WG, I am afraid that it will be even harder for some implementor
reading the draft to understand the difference between integrity
protected and authenticated messages.

This means that if those are allowed, they do require some text
explaing this matter.

> Have we reach a decision yet?  I thought we decided it was ok to send an
> encrypted, authenticated notify in this case and the initiator could take
> action on it because he knows it came from the person that he performed the
> DH exchange with, but the ticket does not reflect that.

I am not sure we reached the decision yet, but I think more text is
needed if that is allowed, thus creating that text might help moving
things forward (i.e send replacement text). 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?

[Tero Kivinen]

Yaron Sheffer writes:
> >From Appendix C: The specification does not say which messages can contain
> N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is
> not yet shown below.
> 
> SF discussion: Paul said, "wherever you wish."

I agree on that. Logical places are:

1) In separate the INFORMATIONAL exchange immediately after IKE_AUTH
   or IKE SA rekey CREATE_CHILD_SA to set the initial window.

2) In the IKE_AUTH or in the IKE SA rekey CREATE_CHILD_SA to set
   initial window.

I do not think there is any need to prefer either one of those two
locations.

Usually the window size is something that is set once after the IKE SA
is created (and after it is rekeyed), and it will never be changed
after that.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #63: Position of arbitrary notify payloads

[Tero Kivinen]

Yaron Sheffer writes:
> Yaron:
> 
> Appendix C: please also mention extension notifications [N+], other than in
> C.6.
> 
> Paul:
> 
> Maybe copy it everywhere like we have [V+]

That is ok for me.

Btw, is there any reason why [V+] is not listed in the IKE_AUTH
excghange with EAP in the intermediate EAP messages and final AUTH
request from the initiator?
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #53: Handling of INITIAL_CONTACT

[Tero Kivinen]

Yaron Sheffer writes:
> Yaron:
> 
> 2.4: Clarif-7.9 is unclear: [this MUST be sent in the first IKE_AUTH
> request.] 'however, receiving parties need to deal with it in other
> requests' - what requests? How? Why should it ever happen?
> 
> SF discussion:
> 
> David Black: if you put initial_contact in anything other than an IKE_AUTH
> 
>   something is wrong, do you have the critical bit on it?
> 
>   Tero: comes from IKEv1
> 
>   Greg Lebowitz: clarify: only pay attention to it if it arrives in
> IKE_AUTH

To clarify how it comes from IKEv1: In the IKEv1 the extra
notification payloads sent along the main mode or aggresive mode
exchanges were not authenticated, meaning that attackers could add /
remove those. Because of this it was considered unsafe to send
INITIAL_CONTACT notifications during the initial phase 1, and it was
usually sent only after the initial exchange as a separate
informational exchange.

As in IKEv2 the IKE_AUTH messages are authenticated, I do not really
see any reason why we should allow INITIAL_CONTACT anywhere else than
in the IKE_AUTH request, but as the generic rule says you can put
status notifications anywhere, and those should not cause errors,
meaning that if INITIAL_CONTACT is sent anywhere else it can be
ignored.

I remember there was also discussion earlier whether the responder can
send INITIAL_CONTACT notification to tell that it does not have any
SAs. The current ikev2bis text says it MUST be first IKE_AUTH request,
meaning it cannot be sent by the responder (which is sending IKE_AUTH
response, not request).

I think the current MUST is ok, and we should just change the
"receiving parties need to deal with it in other requests." to
"receiving parties MAY ignore it in other messages."

I do not want implementations to fail the whole IKE SA because of
someone reused old IKEv1 code and sent INITIAL_CONTACT as separate
INFORMATIONAL exchange. Ignoring it is safe option, as it does provide
interoperability. Processing it in other exchanges should also be
allowed, but not required (i.e. I do not want to make some
implementation non-conformant, just because they want to be backwards
compatible with their old versions which sent INITIAL_CONTACT in
"wrong" place). The whole INITIAL_CONTACT processing is only
optimization and not very important for the IKEv2, as the IKEv2 is
reliable protocol, meaning that other end most likely have already
detetected that the old IKE SA was lost before the initiator
reconnects after crash.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?

[Tero Kivinen]

Scott C Moonen writes:
> > From Appendix C: The specification does not say which messages can 
> contain N(SET_WINDOW_SIZE). It can possibly be included in any message, 
> but it is not yet shown below.
> > 
> > SF discussion: Paul said, $,1r|(Bwherever you wish.$,1r}
(B> 
> Should we prohibit or at least discourage it in the IKE_SA_INIT exchange 
> so that it is not susceptible to third-party tinkering?

The full contents of the IKE_SA_INIT message is also authenticated
after the IKE_AUTH finishes, so there is no security reason to
discourage it in the IKE_SA_INIT. Of course there are other reasons
not to send it in the IKE_SA_INIT. IKE_SA_INIT should be kept as small
as possible. Also the window size only takes effect after the IKE_AUTH
finishes. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation

[Tero Kivinen]

Matthew Cini Sarreo writes:
> I would like to ask the reason behind this. As "live peer detection" is done
> by sending an empty INFORMATIONAL exchange (Encrypted Payload with no
> payloads), wouldn't it better to have a response be constructed in such a
> way so that the requesting peer can explicitly "know" that this
> INFORMATIONAL exchange is a confirmation of the request sent?

This is already done. Each request has unique message-id, and each
response will have same message-id, so other end can always tie
correct request and responses togehter.

> This way, the requester would have to parse the response, and not
> decrypt the message, discover that there is no payload in the
> Encrypted Payload, check if the message is marked as a response and
> assume it is a confirmation of a request. Would a message ID be used
> to check the corresponding request?

It is. In the IKEv2 the exchanges are always request-reply pairs,
which are identified by the message-id (which is incremented by 1 for
each exchange). There is separate request-reply pairs in both
directions (separated by the Initiator flag). 

> And if then the message ID on the responder (to the INFORMATIONAL
> exchange) somehow got messed up and does not match what the
> requester is expecting?

If the message id got messed up, the recipient of that message will
throw that message away immediately as it does not fit the message id
window, and it will then wait for the other end to retransmit the
message with correct message id. If the other end has bug causing the
message ids to be messed up in all responses, then the recipient will
time out the exchange, and tear down the whole IKEv2 SA, as the other
end did not reply to its messages.

Note, that IKEv1 handled message id, and exchanges completely
differently waythan what IKEv2 does, so do not assume anything is
staying same from the IKEv1 to IKEv2.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #28: UDP encapsulation and transport mode ESP

[Tero Kivinen]

> Ticket #28 (new defect)
> 
> Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
> 
> Opened 7 months ago
> Reported by:  kivi...@iki.fi
> Owned by: paul.hoff...@vpnc.org
> Component:draft-ietf-ipsecme-ikev2bis
> 
> >o Implementations MUST process received UDP-encapsulated ESP
> >packets even when no NAT was detected. o The original source and
> >destination IP address required for the transport mode TCP and
> >UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the
> >Traffic Selectors associated with the exchange. In the case of
> >NAT traversal, the Traffic Selectors MUST contain exactly one IP
> >address, which is then used as the original IP address. 
> 
> Getting original source and destination IP address from the traffic
> selectors do not really work currently. Especially when combined with
> the selectors from the packet and when responder is behind nat or
> similar problems. 
> 
> Paul: Not done. Specify replacement text and discuss on the mailing list.

I wrote a longer description of the whole transport mode NAT-T
problem, and also added some text which could be used as parts of the
solution to be added to the IKEv2bis.

The problem is that currently there is no way of doing transport mode
NAT-transport without violating at least one of the following MUSTs in
the IKEv2bis document:

ikev2bis-02: section 2.9:

   o  If the responder's policy allows it to accept the first selector
  of TSi and TSr, then the responder MUST narrow the traffic
  selectors to a subset that includes the initiator's first choices.

  and the generic requirement from the same section which in short
  says responder MUST narrow the traffic selectors to be a subset
  of initiators traffic selectors (this is said in quite
  complicated way in IKEv2bis).

ikev2bis-02: section 2.23:
  ... In the case of NAT traversal, the Traffic Selectors
  MUST contain exactly one IP address, which is then used as the
  original IP address.

RFC4301: section 5.2:
...
   IPsec MUST perform the following steps:
...
   4.  Apply AH or ESP processing as specified, using the SAD entry
   selected in step 3a above.  Then match the packet against the
   inbound selectors identified by the SAD entry to verify that the
   received packet is appropriate for the SA via which it was
   received.

The problem with transport mode NAT-traversal and narrowing and SAD
entry checks is that two end nodes talking with transport mode cannot
work if they have same traffic selectors in both ends. This is because
the packet will look like having different IP-addresses depending
which end is seeing it, thus there is no way that both parties could
agree on any single addresses that would work for both ends.

In my following longer text I explain the solution how the transport
mode NAT traversal can be made to work. This will be protocol change,
but on the other hand it cannot break any existing complient
implementations as there was no way to do this before (even when the
RFC claimed so):
--
Transport mode NAT Traversal


When transport mode is used with NAT Traversal that requires special
handling of the traffic selectors used in the IKEv2. The complete
scenario is like this:


  +--++--++--+ +--+
  |Client| IP1| NAT  | IPN1  IPN2 | NAT  | IP2 |Server|
  |node  |<-->|  A   |<-->|  B   |<--->|  |
  +--++--++--+ +--+

In this scenario there is two address translating NATs NAT A and NAT
B. NAT A is dynamic NAT that maps the clients source address IP1 to
IPN1. NAT B is static NAT configured so that connections coming to
IPN2 address are mapped to the gateways adddress IP2, i.e IPN2
destination address is mapped to IP2. This allows client to connect
server by connecting to the IPN2. NAT B does not necessarely need to
be static NAT, but client needs to know how to connect to the server,
and it can only do that if it somehow knows the outer address of the
NAT B, i.e. the IPN2 address. If NAT B is static NAT, then this can be
configured to the client's configuration. Other options would be find
it using some other protocol (like DNS), but those are outside of
scope of this document.

As other scenarios are just simplications of this complex case (i.e.
where you can just remove NAT A or NAT B), we do not need to consider
them separately.

In this scenario both client and server are configured to use
transport mode for the traffic originating from the client node and
destinationed to the server.

When client starts creating IKEv2 SA and Child SA for sending traffic
to the server, it has triggering packet with source IP address of IP1,
and destination IP address of IPN2. Its PAD and SPD needs to have
configuration matching those addresses (or wildca

Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying

[Tero Kivinen]

Yoav Nir writes:
> I agree with Tero.
> 
> How about replacing this:
>The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
>payload, optionally a Diffie-Hellman value in the KEi payload, and
>the proposed traffic selectors for the proposed Child SA in the TSi
>and TSr payloads.
> 
> With this:
>The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
>payload, optionally a Diffie-Hellman value in the KEi payload, and
>the proposed traffic selectors for the proposed Child SA in the TSi
>and TSr payloads. The TSi and TSr payloads SHOULD include the
>very specifig traffic selectors including the addresses in the packet
>triggering the request, as described in section 2.9.

That is one change that is needed, but in addition I think we need to
say that the TSi and TSr should be the original traffic selectors from
the policy, not the already narrowed down ones that the current child
SA is using.

I.e. if initiator originally offered TSi as 10.0.0.0-10.0.255.255 and
included specific packet of 10.0.0.5 TCP port 25 by sending following
TSi entries:

TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5)
  (0, 0 - 65535, 10.0.0.0 - 10.0.255.255)

and then the responder narrowed it down to per host basic, i.e.
returned TSi as:

TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)

now when the initiator starts to rekey that SA after receiving TCP
packet going to that SA (otherwise he would not be rekeying this SA),
and lets say the packet is 10.0.0.5 TCP port 80, so he should send TSi
when rekeying as follows:

TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5)
  (0, 0 - 65535, 10.0.0.0 - 10.0.255.255)

Note, that the second entry is still the whole 10.0.0.0 - 10.0.255.255
range as specified by the policy, not the already narrowed down range
of 10.0.0.5 - 10.0.0.5 which the current child SA is using.

If the responders policy is still same it will still return same TSi:

TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)


If the responders policy has been changed so that port host SAs are no
longer required it can instead rekey the old SA to have TSi which
would cover the new range, i.e. widen up the traffic selectors from
what they used to be.

If this is not done, then this kind of widening is not possible,
meaning that even if the policy is fixed the original more narrow
policy is still used.

I have seen implementations where the traffic selectors are sent out
(and narrowed to) based on the traffic selectors used in the child SA
now, not what is specified in the policy. The traffic selectors used
in the child SA can always be only more narrow than what is in the
policy (if child SA would have more wider traffic selectors than what
is allowed by policy it would be violating the policy, and it would be
deleted).

I would like to have text saying that the original traffic selectors
from the policy SHOULD be used. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #80: UDP encapsulation needs to be negotiated

[Tero Kivinen]

Yaron Sheffer writes:
> Herbert: 
> "Implementations MUST process received UDP-encapsulated ESP packets even
> when no NAT was detected."
> 
> was added to the draft. This has the potential to create black holes if
> deployed in the field, unless all implementations always use UDP
> encapsulation regardless of NAT.

I do not think it creates any more black holes than what is generally
generated by the broken firewalls in the middle.

There is already now black hole generated by IKEv2 implementations
doing NAT detection incorrectly, and enabling NAT-T even when no NAT
is detected (I have seen such implementation).

If you drop all UDP encapsulated ESP packets if no NAT was detected,
then this will cause black hole, as you will not receive any of his
IPsec packets as you drop them, and he might or might not receive your
packets depending whether he requires them to be UDP encapsulated or
not.

In this implementation I have seen this was not really a problem, as
both ends supported MOBIKE, which requires processing both UDP
encapsulated and plain IPsec always, thus both ends were able to
process packets, but UDP encapsulation was used in one direction but
not in other.

> The problem is that if a peer behind a firewall (with no NAT) that
> only allows inbound packets which are in response to outbound
> packets performs UDP encapsulation without NAT, and the remote peer
> responds without UDP encapsulation, then all data packets from the
> remote peer will be dropped.

In normal case this means that the IKE SA will be formed, but no IPsec
traffic will go through in either direction. I.e. neither end will
enable UDP encapsulation as no NAT is detected, thus both ends will
use plain ESP, and those will not go through, so this requirement does
not change the situation.

Note, that the statemenet added does not say anything that SENDING
UDP-encapsulated ESP packets would be required or preferred or even
allowed (it is not forbidden either). The text allows easier
extensibility as now we know that all ends will be able to process
both UDP encapsulated and normal packets always when receiving, so if
we later make extensions which enable sending them, we know that it
will work with old implementations too.

> Looking at this from the point of view of the remote peer, the only
> practical solution would be to always employ UDP encapsulation, regardless
> of NAT detection.

No. There is no way to get IPsec working through that kind of broken
firewall. The firewall policy is clearly saying that IPsec is not
allowed, thus any way of trying to bypass that policy would be bad... 

> Now through discussion on the mailing list it appears that this statement
> was motivated by a need in MOBIKE to deploy UDP encapsulation when NAT is
> not detected. So assuming that we want to cater for this in IPsec, we should
> extend IKE to explicitly negotiate UDP encapsulation, rather than having it
> rely on the result of NAT detection.

Adding full UDP encapsulation negotiation would be too big protocol
change to the IKEv2, I do not think we can put it to the current
IKEv2bis. It could be added as extension in the future, but I am not
sure if such is really needed. Anyways UDP encapsulation negotation
with backward compatibility is much simplier if you know that IKEv2
implementations can processes either types of packets always.

If you want to force UDP encapsulation, simply fake a NAT on the path
(i.e make NAT DETECTION payloads not to match).

The new text will allow some cases to work where for some reason two
peers do get NAT detection differently. This might be because of bugs
(in NAT detection), or because of attacker modifing packets in one
direction etc.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying

[Tero Kivinen]

Yoav Nir writes:
> The traffic selectors in the REKEY exchange are not currently
> specified. If were designing IKEv2 from scratch, I would be in favor
> of removing traffic selectors altogether from REKEY exchanges - I
> don't think it should be called a "rekey" if you get a totally
> different SA.  This does raise the question (that has been asked
> before) of why do we really need REKEY_SA exchanges as opposed to
> regular exchanges.

I think the reason for REKEY_SA is to know which SA is being replaced
with the one we are creating now. I.e. from where we can move
statistics to, and from which SA we should move traffic to this new SA
(even before the old SA expires, but after we know other end has also
installed the SAs, i.e. after responder sees traffic in the new
incoming SA).

For example in our implementation rekeyed SA shares same internal SA
slot in the engine, i.e. we have one SA slot having two associated
crypto contextes and SPIs, and only one of them are in active use.
I.e. old one is in use until traffic moves to new one and then later
the old ones are removed (but might still be used to decrypt traffic
as there might be out of order packets coming in) etc. I.e. it makes
implementations easier and more efficient when you know which SA is
going to be replaced with the rekey.

In IKEv1 you usually tried to do same by inspecting the selectors and
tried to guess which one was the old SA being replaced. This is not
possible in IKEv2, as it is normal to have multiple overlapping Child
SAs with same selectors for different QoS classes.

> As it is, I think the initiator of the rekey (not necessarily the
> same as the initiator of the old SA) should keep the selectors in
> the old SA, and the responder should either accept of reject, but I
> don't think we need to capitalize the SHOULD.

Responder should do normal narrowing of the selectors, it should not
ever reject the selectors. I mean if the selectors initiator offered
is superset of the old selectors of the SA, they cannot be against the
policy of the responder, thus the responder should either accept wider
ones or narrow it down to subset of the offered selectors as normally. 

> In some implementations, the REKEY is generated because of traffic
> passing the IPsec stack when little time remains before the child SA
> expiration. It may be much more convenient to rekey with the
> narrowed selectors rather than locating an SPD entry which is a
> superset of the SPD cache entry that matches this SA.

I agree that should be allowed, but in most cases the implementations
do have pointers back to the original SPD entry anyways, and in that
case they SHOULD use the original selectors from the SPD entry if they
are readily available.

> I think the rekey initiator SHOULD propose any superset of the
> current selectors, which can be the current selectors, or anything
> that matches its policy.

Yes. 

> I don't think we should recommend doing one or the other.

I would prefer to say "SHOULD" for the selectors from the original SPD
entry, but I can accept also the wording saying that either one can be
used. 

> We can and should, however, require the responder to not expect the
> traffic selectors in a rekey-SA to exactly match those of the
> current SA.

Yes, this is something we should at least require (even as MUST).

Now that I think more of this I think the initiators proposed
selectors MUST always be same or superset of the old SAs selectors.
They cannot be narrower than what was used before, as that would
normally mean that the policy of the inititor was changed so that old
SA is no longer valid with the new policy, which means it should be
deleted and new SA created (and this is so rare case, that we do not
need to optimize performance for this). Earlier I though we could use
rekey in that case too, but I think it is better to say it MUST be
same or superset of the currently used selectors.

The responder should narrow the offered proposal down to either
superset of the current used selectors, or same as currently used
selectors. Again it really cannot narrow it down to anything smaller
than currently used, as in that it case the current SA is against its
policy, and should be deleted.

If we go with those rules (i.e. SA can be rekeyed only to superset of
the current SA, never to subset), then we actually do NOT need the
specific selectors from the packet, as we always know that the subset
where we need to narrow it down to, is the one containing the old SAs
selectors. 

So perhaps we should change the resolution to issue #12 (and #11):
--
  - When initiator proposes traffic selectors when rekeying Child SA,
the proposed traffic selectors SHOULD be either superset of the
traffic selectors used in the Child SA (i.e. come from the
currently active (decorrelated) policy), or same as the traffic
selectors currently used.

  - When responder narrows traffic selectors d

[IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer

[Tero Kivinen]

Matthew Cini Sarreo writes:
> In such a scenario, it might be required to have different D-H groups for
> different peers. Due to the ID payload being inexistant at this time, is
> there a way (that is allowed) to identify a peer during IKE_SA_INIT (for
> example, based on an IP address that has been stored in a configuration file
> that is known to always be for a certain peer), or are such identification
> methods (IP-based during IKE_SA_INIT just by checking the IP address source
> in the IP header of an IKE_SA_INIT message) prohibited?

Does not really sound like reasonable real world use case, and I would
firstly try to convince people that hosts should never ever allow
anybody to use too weak cryptographic suites, and if you only allow
strong enough ones, then it does not matter which one of those strong
enough ones is used.

But to your question.

Yes, you can select the IKE SA cryptographic algorithms based on the
IP address of the request. Actually you can use whatever means you
can, including the phase of the moon, but usually only useful thing
you have is the IP address of the other end.

This of course has the problem that if the other does not have fixed
IP-address, then you might have problems (or you end up problems if
you have multiple hosts having dynamic IP-addresses and their required
policies do not match).

If there really is strong requirement that specific host MUST use some
cryptographic suite that is not allowed for another host and both of
them use dynamic IP-addresses, you can always do so that you do
IKE_SA_INIT exchange and then when you see IKE_AUTH message, you know
the identity, and then you can verify that your IKE_SA_INIT parameters
were correct, and if so continue. If your IKE_SA_INIT parameters were
wrong, then you simply store information to your local cache saying
that host from this IP address, should use these IKE_SA_INIT
parameters next time, and return some fatal error message to IKE_AUTH.
When the initiator then retries and sends next IKE_SA_INIT, you can
then check your cache, and see that for this IP-address you should use
these parameters, and use those and then continue. Then in the
IKE_AUTH you again verify that your parameters were correct and
continue.

> P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and
> Cookies), par. 2 which states:
> "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI,
> not using (for example) the source IP address of the packet."
> But the "identification" for fixed configuration purposes would be before
> this, as the packet would not be mapped to an SA, but a configuration for
> the SA resulting my that message would be loaded from configuration.

That text means that the source address of the UDP IKE packet does not
matter when finding the IKE SA state. When doing lookup to PAD you can
use the remote IP address of the peer (RFC 4301, PAD). If PAD contains
restrictions that these PAD entries must have remote peer location of
IP address XXX, then it is best to first concentrate your searching of
the suitable PAD entry for new connection to those PAD entries having
matching IP-address. If you only find one PAD entry then you can
assume that this will be the one that will be used, and then later in
the IKE_AUTH verify that your guess was correct by doing PAD/SPD
lookup again using the full information available and check that you
get same PAD/SPD entry back.

For example in our implementation the configuration can specify that
this IPsec connection must have local and/or remote IP as specified in
the configuration, and then when new connection comes in we first
search entry matching both to the remote and local IP, and if such is
found, we guess that is the correct one. If that is not found, we
search one having correct remote IP, and if that is not found then we
search for having correct local IP, and otherwise use defaults.

Later we then verify that the final selected IPsec connection is same
than what we guessed earlier (or at least has same parameters for IKE
SA).
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Paul Hoffman writes:
> Greetings again. Tracker issue #98 is the same as the message that
> Pasi sent to the mailing list last month; see
> .
> There is disagreement among the authors of the session resumption
> draft how to deal with this issue. 
> 
> One proposal is to add text similar to Pasi's to the document in
> order to let implementers understand all the things that they might
> need to do to prevent damage from a replay attack. If this is the
> method chosen, it should probably be as a section in the main body
> of the document, not as a "security consideration" because the
> issues are more operational than security. 
> 
> A different proposal is to get rid of the one-round-trip mode and
> have the protocol always take two round trips. This prevents the
> attack that Pasi brings up, at a higher cost for the clients and
> server. 
> 
> If you have a preference between these two proposal, please state it now. 

This comes back to again to what use the resumption is aimed for (I
tried to ask this in meeting, and it seems nobody knows, so it makes
it impossible to think whether some optimization in the protocol is
needed or not).

Anyways, I would prefer to have safer protocol even if it would be one
more round trip. It would also make protocol simplier, as we would not
need to have separate optional cookie exchange version.

So I would vote for 2 round trip version of the protocol.

BTW the ticket #98 has wrong component (draft-ietf-ipsecme-ikev2bis),
it should have ikev2-resumption instead. Also the ticket component
names are not consistent, there is both ikev2bis and
draft-ietf-ipsecme-ikev2bis and only the last one of them is used,
but all other components ignore the draft-ietf-ipsecme part... 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2

[Tero Kivinen]

Paul Hoffman writes:
> At 4:44 PM -0400 4/10/09, black_da...@emc.com wrote:
> >That looks like an oversight at least wrt RFC 4869.
> 
> Actually, this started with an oversight in RFC 4543. Section 5
> clearly says that it is for IKEv1 and IKEv2, but section 9 only
> seems to cover IKEv2.

Yes. 

> >Chairs (of ipsecme) and Pasi (AD) - is a new RFC needed to
> >allocate this value, or is there a lower overhead and faster
> >means of getting this done?
> 
> This can probably be done by Pasi, given the nature of the error.
> Otherwise, we probably need a revision to RFC 4543. 

It would be easier to fix that if the value would be missing from the
IKEv2 registry as those are expert review actions.

The whole ikev1 (http://www.iana.org/assignments/isakmp-registry)
registry is completele mess. For example the top level iana list
(http://www.iana.org/protocols/) only contains following registries
pointing to the isakmp-registry:

  - ISAKMP AH Transform Identifiers
  - IPSEC Security Association Attributes
  - ISAKMP Identifiers
  - Signature Encoding Algorithm Values

The RFC2407 lists more registries:

   6.1 IPSEC Situation Definition
   6.2 IPSEC Security Protocol Identifiers
   6.3 IPSEC ISAKMP Transform Identifiers
   6.4 IPSEC AH Transform Identifiers
   6.5 IPSEC ESP Transform Identifiers
   6.6 IPSEC IPCOMP Transform Identifiers
   6.7 IPSEC Security Association Attributes
   6.8 IPSEC Labeled Domain Identifiers
   6.9 IPSEC Identification Type
   6.10 IPSEC Notify Message Types

And those are the registries actually included in the isakmp-registry
file.

In addition to those the isakmp-registry also contains the "ISAKMP
Domain of Interpretation (DOI)", and "Next Payload Types" registries.
The "Next Payload Types" which was created afterwords when we noticed
we do need it. I do not think its creation is specified in any RFC.
Don't even know when the DOI registry was created. 

Most of those IKEv1 registries do require RFC and IESG review (IPsec
Situation Definition, IPSEC Security Protocol Identifiers, IPSEC
ISAKMP Transform Identifiers, IPSEC AH Transform Identifiers, IPSEC
ESP Transform Identifiers, IPSEC IPCOMP Transform Identifiers, IPSEC
Identification Type). Rest just require Internet Draft to specify
it...

As this change to the isakmp-registry changes the IPSEC ESP Transform
Identifiers registry, which do require Standard Track RFC or IESG
review, I think we cannot simply modify the registry, but we at
minimum need to make errata for the RFC4543 which reserves values also
from the IKEv1 registry.

Of course as everybody should be using the IKEv2, and everybody should
be moving away from the obsoleted IKEv1 protocol, we can also just say
that you cannot use those algorithms with obsoleted IKEv1 protocol,
and you need to use IKEv2 for it :-)

Anyways IANA should fix their toplevel list
(http://www.iana.org/protocols/) to include all the registries listed
in the isakmp-registry file, i.e.:
--
IPSEC Situation Definition
RFC 2407
Standards Action

IPSEC Security Protocol Identifiers
RFC 2407
0-248 Standards Track RFC; 249-255 Reserved for private use
amongst cooperating systems

IPSEC ISAKMP Transform Identifiers
RFC 2407
0-248 Standards Track RFC; 249-255 Reserved for private use
amongst cooperating systems

IPSEC AH Transform Identifiers
RFC 2407
0-248 Standards Track RFC; 249-255 Reserved for private use
amongst cooperating systems

IPSEC ESP Transform Identifiers
RFC 2407
0-248 Standards Track RFC; 249-255 Reserved for private use
amongst cooperating systems

IPSEC IPCOMP Transform Identifiers
RFC 2407
0-47 Standards Track RFC; 48-63 Reserved for private use
amongst cooperating systems

IPSEC Security Association Attributes
RFC 2407
1-32000 Specification Required; 32001-32767 Reserved for
private use amongst cooperating systems

Signature Encoding Algorithm Values
RFC 4359
Standards Action

IPSEC Labeled Domain Identifiers
RFC 2407
First Come First Serve 

IPSEC Identification Type
RFC 2407
0-248 Standards Track RFC; 249-255 Reserved for private use
amongst cooperating systems

IPSEC Notify Message Types
RFC 2407
8192-16000 and 24576-32000 Specification Required;
16001-16383 and 32001-32767 Reserved for private use amongst
cooperating systems 

ISAKMP Domain of Interpretation (DOI)
RFC ?
Specification Required

Next Payload Types
RFC ?
0-127 ???, 128-255 Reserved for private use amongst
cooperating systems 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2: Moving Child SA traffic from an SA to a new SA when rekeying

[Tero Kivinen]

J. Sun writes:
> Matthew,
>   It has to be Case #2.  No where in the CREATE_CHILD_SA - IKE_SA Rekey 
> exchange do you update to the other endpoint the new CHILD_SA SPIs - 
> without exchanging the CHILD_SA SPIs, you'll most definitely run into 
> interoperability issues, namely you'll start black holing traffic.  As a 
> result, it would be what you consider a copy.  However, you shouldn't 
> really think about it in that way.  Depending on implementation, 
> generally speaking - CHILD_SAs existing in a SAD would simply have an 
> object that essentially references the parenting IKE_SA.  After the 
> successful IKE_SA Rekey, the CHILD_SA simply would update this object to 
> simply point to its new parent, the rekeyed IKE_SA.  But to qualify, it 
> all really depends on implementation.

Actually it is more like of move, not copy, i.e. just like you explain
in the end. There is no two copies of the same Child SA, there is only
one, and that one has exactly one parent SA, i.e. either the old or
new IKE SA, depending on where we are at the IKE SA rekey process.

I.e. it is mostly:

IKE SA A - Expiring  IKE SA B - Rekeyed
No Child SAs Moved Child SA from A
all Childs are moved to new IKE SA   SPI (incoming) 0x12345678
 Protocol AH
 Same cryptographic suite
 as A's Child SA (moved)

I.e. after that you MUST send all management traffic relating the
Child SA using the new IKE SA B, you cannot use IKE SA A anymore for
delete notifications or similar relating to the Child SA which was
moved.

Note, also that in case of the simultaneous rekeys, you need to move
the Child SAs to the winning IKE SA.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #63: Position of arbitrary notify payloads

[Tero Kivinen]

Paul Hoffman writes:
> At 3:55 PM +0300 4/3/09, Tero Kivinen wrote:
> >Btw, is there any reason why [V+] is not listed in the IKE_AUTH
> >excghange with EAP in the intermediate EAP messages and final AUTH
> >request from the initiator?
> 
> We could add it, but I think that would surprise some implementers.
> Is it really needed? 

I do not think any of the [V+] payloads are really needed, as section
3.12 clearly says that "A Vendor ID payload may be sent as part of any
message.".

My question was more of "was this omission trying to say something".
I.e. does that it is NOT listed in that those messages trying to say
that those messages are not logical place for vendor ID payloads. (I
actually only now noticed the text about most logical place). 

I would at least expect that vendor ID payloads could be also used in
the last AUTH message from client to server, i.e. after the EAP
authentication is finished. The server is already marked so that it
can use [V+] in its last response. I.e. for server the logical places
are first and last response, but for client the only logical place
listed is the first request, last request was ommitted.

I agree that during the EAP exchanges itself (the ones repeted 1..N
times) the vendor ID payloads might not be that logical (as most
likely all extensions during that is done inside the EAP messages
itself, not as IKEv2 vendor ID payloads).

But I think the last request is bit different case, and I myself
consider that as one that could be logical place for vendor ID
payload for some extension.

Currently it is bit funny that only places where vendor ID payloads
are not supposed to be most logical are:

  - IKE_AUTH exchange with EAP: EAP payload request
  - IKE_AUTH exchange with EAP: EAP payload response
  - IKE_AUTH exchange with EAP: last request from client
  - CREATE_CHILD_SA for Child SA: generic error case response
  - INFORMATIONAL exchange: request
  - INFORMATIONAL exchange: response

It is not very "most logical" locations if it is listed in 71% of
cases (i.e. 15 packets out of 21).

I think the most logical place currently to send those vendor ID
payloads is only during IKE_SA_INIT exchange request, and IKE_SA_INIT
exchange normal response.

We currently do not have any extensions which would send them in any
other locations, and I have not seen any implementations sending them
in any other locations yet. If you want to pick the "most logical"
place, then I would only put it on those exchanges, and say that they
can still be part of any other message too if needed. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Narayanan, Vidya writes:
> Hi Yaron, 
> We are going back to revisiting consensus here and re-explaining the
> use cases and I'd certainly like to keep this to as minimum a
> revisit as possible.  The use cases go back to what has been
> documented in the problem statement we published a while back -
> draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you
> should be still able to get to the draft.

>From the ipsecme charter:

 Failover from one gateway to another, mechanisms for detecting
 when a session should be resumed, and specifying communication
 mechanisms between gateways are beyond the scope of this work
 item.

Thus failover from one gateway to another is outside the scope of this
document. If I remember right most of the use cases in
draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not
resumption use cases.

> As a key point, I'll note that the situation where resumption is
> used here is a handoff case for a particular client and does not
> involve all clients connecting at once, where DH could be a problem.
> And, in these cases, there is no user interaction involved - the
> mobile devices are doing everything they can to make handoffs
> seamless and work with no user or even application involvement.
> 
> If you are only worried about the case of simultaneous reconnection
> of thousands of nodes, you can feel free to always use the 2-RT
> method in your gateway implementation - I am pointing out that it is
> not the universally applicable use case.

>From the abstract of the resumption document:

   To re-establish security associations (SAs) upon a failure recovery
   condition is time consuming especially when an IPsec peer (such as a
   VPN gateway) needs to re-establish a large number of SAs with various
   end points.  A high number of concurrent sessions might cause
   additional problems for an IPsec peer during SA re-establishment.

So at least it was seen as important use case, and is thats why
included in the abstract (and the ipsecme charter text). 

> And, in most cellular deployments, IPsec is used for untrusted
> access networks (e.g., WLAN), while the DHCP servers and AAA servers
> are accessible from other access networks as well. And, a handoff
> from cellular to WLAN needs to be seamless - you can envision an
> IPsec SA being set up all the time, but only resumed and actively
> used after you handoff to WLAN.

Hmm.. This is again something completely different what I tought for
what the resumption protocol is supposed for. For example for this use
it would be useful to have have some way to force deletion of the
state from the server, i.e. say that this IKE SA is now going to go to
sleep, so you can remove the state, and there is no need to do dead
peer detection on it. The current protocol do not have anything like
that, and if you delete IKE SA you also delete the ticket, so that
mechanism cannot be used for that.

I still do not think making the 1 RT protocol to 2 RT protocol in that
case would really cause any noticeable effect to the actual handover.
Especially as you still most likely have the cellular network there to
be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the
WLAN, thus only thing that is affected is that traffic moves 100ms
later from cellular to WLAN.

On the other hand security problems are big issue, as you most likely
try to IKE_SESSION_RESUME exchange over any WLAN you happen to see,
thus you effectively broadcast your tickets to attackers at will, so
attackers can simply take those tickets and sent them to server and
get your session resumed, but not forward any other traffic. Also any
firewall allowing port 500 packets out but not in, will cause similar
effect, as you will not get reply back, but server will consume your
ticket.

That case also brings out completely new issue which has not been
discussed before, i.e. whether the IKE_SESSION_RESUME must come from
the same IP-address than what was used before for the IKE SA, i.e. can
the IP-addresses change during the IKE_SESSION_RESUME. If that is
allowed, then what about NATs, i.e. is it allowed that even when there
was no NAT between hosts before, there is new NAT found during the
IKE_SESSION_RESUME?

Those are not covered by the current document, and at least something
MUST be said about those issues.

After this example use scenario, I am even more convinced that 2 RT
protocol is better and needed, especially if we do allow IP-addresses
change, and might need to do NAT-T detection on the IKE_SESSION_RESUME
exchange too. Allowing IP-addresses change means that the network
where the packets can come in, are different, meaning they might have
misconfigured firewalls or similars there, and killing your resumption
ticket by just trying to connect through broken firewall is bad idea.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-02.txt

[Tero Kivinen]

During the other discussion I read the
draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more
generic comments to it:

---

In Section 3 we present 2 use cases, and then after figure 1 start
talking about "In this scenario..." and I think that refers to first
use scenario described in second paragraph of section 3, not the
second use scenario described just above that in third paragraph. It
would be useful to change the "In this scenario..." to explicitly
mention which one of those two scenarios it is talking about. As far
as I can understand the second use scenario is not talked in detail
anywhere, i.e. only reference to it is 3rd paragraph of section 3.

---

In Section 4.3, it might be good idea to clarify that reuse of the
ticket is when you successfully use it, not just when you try to use
the ticket, i.e. client can try to send IKE_SESSION_RESUME exchanges
every now and then to the server and ticket is only really used when
it gets reply from server.

---

Also the text "The client SHOULD NOT use this exchange type unless it
knows that the gateway supports it." is bit pointless, as at least
from my understanding is that when server presents ticket to client it
indicates the gateway supports this, thus if client has ticket it can
use this exchange. If client does not have ticket it cannot use this
exchange anyways, as ticket is required for this exchange.

---

I would also like to rename TICKET_OPAQUE' to something else, perhaps
use TICKET_REQUEST, TICKET_REPLY, TICKET_PRESENT or similar names
instead (main reason for that is that I like to define those names to
actual defines in C-code or similar, and then I need to rename
TICKET_OPAQUE' to something like TICKET_OPAUQE_DOT or so).

---

Why is the IDr there? I know I asked this before, but I do not sill
understand why it is there. Gateway cannot have multiple identities
having different session resumption caches, as IDr is encrypted,
meaning gateway needs to parse presented ticket first, and that ticket
must have information of which identity the connection is connecting
so it can select suitable session resumption cache. Section 4.7 says
that IDr is obtained from the new exchange, so that seems to indicate
it is used, but IDi, and IDr is used to check PAD, which is then used
to check SPD entries etc, and I do not think we want to redo policy
lookups at this point.

Also in normal IKE we do not directly use the IDr that client sent, we
use that as hint when selecting one of the our own allowed IDr for
this connection. The text in 4.7 would indicate that we directly use
the IDr client sent us as is.

The IDi was already removed, but is there any reason to keep the IDr
there? Even if it is kept, the section 4.7 will most likely need text
saying that IDr is selected as normally, i.e. the IDr from exchange is
only used as hint. Also note that the gateway does not tell back to
the client which IDr it finally decided to use...

---

Also still in section 4.3 when talking about the response packet, the
text about what is filled in the SPI fields is wrong. For the response
packet the SPIi value is of course copied from the request, and SPIr
is filled with random number allocated by the responder (gateway).

---

Section 4.3 also needs to clarify what is going to be message IDs of
the exchanges. Especially with the 2 RT version there is two options,
i.e. it could be that the cookie exchange has message ID of 0, and
actual exchange has message ID of 1. When the cookie exchange was
optional, then it was quite clear that all of the IKE_SESSION_RESUME
exchange messages have message ID of 0.

---

In section 4.7 it says "The sequence numbers are reset to 0.". I was
trying to search that earlier, but didn't find it because I searched
using "Message ID" text... Unfortunately IKEv2 document uses both
"sequence number" and "Messsage ID". It uses "Message ID" bit more,
and good thing with "Message ID" term is that it cannot be confused
with the sequence numbers of the ESP/AH packets. I would recommend
changing that text to "The Message ID counters are reset to 0.".

---

Section 5.2 says that "The lifetime of the ticket carried in the
N(TICKET_OPAQUE) notification SHOULD be the minimum of the IKE SA
lifetime and its re-authentication time", and also that "The gateway
SHOULD set the expiration date for the ticket to a larger value than
the lifetime of the IKE SA."

That is bit confusing, and at first looks like it is conflicting. I
assume it was supposed to say that the lifetime sent in the ticket is
actually different that what is enforced by the server, i.e. server
should allow ticket also after the life time sent to client? Hmm.. on
the other hand client MUST NOT present ticket which is expired...
Actually I am not sure what the current text is trying to say. I.e. is
the ticket lifetime supposed to be same or smaller than IKE SA
lifetime, or larger?

(On the other hand I still think the whole lifetime concept should be
removed from this document, but 

[IPsec] Multiple payloads of same type

[Tero Kivinen]

Kalyani Garigipati (kagarigi) writes:
> Please validate if the following is true.
> 
> Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM,
> TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE,
> DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads.

Encrypt MUST be last packet, thus that also limits that there can be
only one of such payloads in packet.

For all others there is no explicit restriction that they cannot
appear multiple times, but on the other hand the exchanges we now have
do not ever put multiple SA, KE, IDi, IDr, AUTH, Ni/Nr (Nonce), TSi,
TSr, or EAP payloads in the same packet.

For CERT, CERTREQ, N (notify), D (delete), V (Vendor ID) it is clear
that there CAN be multiple payloads of those types in same packet.

For CP (configuration payload) it not clear whether there can be
multiple or not, but I would expect most implementations expect to
find only one, and will only use one.

In future someone might make extensions which puts multiple CP
payloads in same packet, but currently we do not have such.

> Like if we get packet as HDR, SA1, SA1, KE, N
> We should reject it ?

Best would be to check first the exchange type, and check out that all
mandatory payloads which are required for that are there. Also when
parsing it should be quite ok to stop parsing immediately when you see
for example 2nd encrypted payload, or 2nd SA payload (In IKEv1 we
could have multiple SA payloads in one quick mode exchange, as there
was option to create multiple IPsec SAs at once, but that is not
allowed in IKEv2). After that parsing all optional payloads (notifies,
vendor id payloads, etc).

Then the question is whether there is any need to check if there is
any extra payloads in the exchange, and if such is found what to do
(lets say someone puts configuration payload as part of the
IKE_SA_INIT instead of IKE_AUTH). For this there is no clear answer,
if you want to be able to work with future extensions without breaking
when seeing them, best might be just ignore them.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Yaron Sheffer writes:
> However, given that normal NAT detection happens during IKE_SA_INIT, can you
> clarify why this would work better if we had a 2 RT protocol?

I think this should explain it:

> > exchange too. Allowing IP-addresses change means that the network
> > where the packets can come in, are different, meaning they might have
> > misconfigured firewalls or similars there, and killing your resumption
> > ticket by just trying to connect through broken firewall is bad idea.

I.e if you are always assuming the network is same, you do not need to
consider someone adding broken firewall in the middle. If on the other
hand you just happen to try every WLAN your client sees on its way,
there is most likely going to be few broken / misconfigured firewalls
/ NAT boxes etc on the way, and the 1 RT protocol will quite often use
your ticket, without you ever noticing it, as reply packets will not
reach you.

I.e. it is not really change required by the protocol, but the
operating environment changes to much more unreliable and untrusted,
meaning the protocol should be more robust against attacks.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #102: What to do about {{ }} notation in ikev2bis

[Tero Kivinen]

Paul Hoffman writes:
> Since its first draft, the IKEv2 bis document has had flags for
> where new text came from RFC 4718, such as "{{ Clarif-6.1 }}" and
> "{{ Clarif-4.2}}". Using a related notation, we have also marked
> where text that originally existed in the top-heavy listing of
> notifications has been moved into the body of the text that relates
> to the notification, such as {{ 3.10.1-17 }} and  {{ 3.10.1-35 }}.

Those have been helpful few times. 

> Can we get rid of the "{{ }}" notations in the next version of the
> draft? If not, how long do we want to keep them? 

I think we can get rid of those {{ }} marks now, as I think all
changes from the clarifications rfc are already in. If someone still
needs to find where the change came from, he can get this -02 version
and check the markings from there.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Narayanan, Vidya writes:
> This is really just a terminology issue.  Most of the use cases in
> that document are applicable to resumption.  In fact, the current
> solution for resumption is based on what was produced as a result of
> that problem statement (combined with Yaron's draft at the time),
> with the ability to exchange failover gateway candidates removed.
> In other words, we are not handling anything specific to failovers,
> but, prior to this charter and WG, "failover" included resumption in
> the work we did.

Main thing between resumption and failover is that resumption assumes
you reconnect back to same host, as in failover you can reconnect to
another host. I myself consider resumption as subset of the failover
cases, i.e. failover cover more things than what resumption itself
covers.

Note, that charter explictly mentions that the resumption can also be
to the cluster of closely cooperating gateways, but cooperating
protocols inside that cluster are not part of the our scope.

> > while you are doing DHCP + IKE_SESSION_RESUME etc on the
> > WLAN, thus only thing that is affected is that traffic moves 100ms
> > later from cellular to WLAN.
> 
> And, btw, WLAN is only one type of untrusted network - other
> scenarios may be cellular-to-cellular handoffs in roaming scenarios,
> cellular to WiMAX handoffs, etc. In some of these cases, there are
> even RF limitations if you are using a single radio, multi-mode
> chipset.  I'd prefer that we keep the discussion on the RF systems
> itself out and see what best we can do with our protocols.

With WLAN and so on I do not think the problem is the RF part, I think
it is the DHCP and so on part. For example in IETF it usually takes me
about 10 seconds to just to get DHCP address when I first time connect
to the network (for some reason it seems the servers always answer
only after 2-3 retries). I have not really seen WLAN networks that
offer anywhere near the subsecond connection times you seem to assume
here.

It might be true in the cellular-to-cellular handoffs, but do you
really use IPsec and resumption on such environments. I would expect
mobike would be much better used there, as if you need IPsec for one
cellular network, you might as well do it always. 

> Obviously, the firewalls need to be handled properly if the operator
> wants this to work - so, that is not the primary issue.

If you start to talk about WLANs, then you are not talking about
operators, you are talking about random basestations someone has set
up somewhere. I can assume network operators to configure their boxes
properly, I cannot really assume random home user for setting their
WLAN basestation properly.

> I don't understand what you mean by "not forward any other traffic"
> in your description of the attack. The attacker does not have the
> keys to decipher any of the actual packets.

The thing that makes replay attacks harder is that attacker does not
get the ticket he could replay. If you walk around on the street and
see some random WLAN named "open wifi" and your phone decides to see
if it works, and gets DHCP address, and after that tries resumption to
gateway, you just sent that ticket to attacker. Attacker will then
take that packet from the air, or from the basestation, and use it to
attack, i.e. after he takes that packet and sends it to gataway (for
example with fake source IP, so return packets never reach you), then
your ticket is killed, and your accounts billing started going.

> The only thing the attacker can do is replay a ticket *after* it has
> already been sent by the client - in this case, we already talked
> about some limited backend state the gateway can maintain to limit
> the impact due to replays.

Yes, after client sent the ticket, but that does not mean server ever
got that ticket from client. I.e if the "fake" WLAN is set up so it
will drop all UDP port 500/4500 packets, you never get any IPsec
resumption on that network, but you still assume your ticket is valid
as for your point of view it was never used. The attacker can see that
ticket, and can then mount the attack.

Or it could be that the WLAN is set up to allow any UDP packets out,
but only "known" UDP packets in (dns and nothing else). In this case
you yourself make the attack, i.e. you kill your ticket by sending it
to the server, but server's reply never reaches you, so you still
think you have not used the ticket, but server has done that. 

> The protocol does allow for IP address changes and also allows the
> client to request a new IP address from the gateway for its internal
> IP address - do you see a reason why this doesn't work?

Other than the fact that draft does not mention it, no. As an
implementor, I would add checks that IP address must be same, as there
is no mention that IP-addresses could change. Also I would not send
NAT detection payloads, as they are not mentioned in the draft.

If such feature is wanted, it MUST be specified in the document too.
Do not assume

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Lakshminath Dondeti writes:
> > I still do not think making the 1 RT protocol to 2 RT protocol in that
> > case would really cause any noticeable effect to the actual handover.
> 
> How do you know this?

Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as
DHCP delays on WLAN networks. And there is already way to do that in 1
RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of
the network or IP-address in 1 RT.

Resumption should not really be used for that.

Resumption means that something caused the IKEv2 SA in the client to
removed, without telling that to the server, and thats why client
decided to use resumption instead of just continuing using the IKEv2
SA it has up and running.

If we take the network outage example from the charter, the duration
of network outage is usually MUCH, MUCH longer than the 2 RTs required
to reconnect to the server.

> I ask because, I would like to use those arguments to tell people
> who are experts in handovers that multiple RTs don't matter.

Tell them to use correct protocol on correct places. If they want
subsecond recovery from the handover from one network to another, they
should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even
with MOBIKE it usually takes several seconds for the nodes to actually
react that they have lost connectivity, and needs to start corrective
actions, but if we assume subsecond recovery is required, then we can
also assume the network can immediately tell when recovery actions are
required).

> Even if this happens, the payoff for the attacker is very little since 
> the legitimate parties can always establish another connection.

No, he does not, as if he was trying to do handover from cellular to
WLAN, he would simply continue using cellular in that point, but the
accounting for example would be enabled for both (i.e. for servers
point of view he is using WLAN and cellular simulatenously, from
clients point of view he using only cellular).

Again then when he finally gets WLAN which works, he suddenly have 3
RT protocol to use (trying resumption, failing that, and falling back
to full IKE) with user authentication, and possibly even user
interaction.

> The quality of experience would be bad because another session needs
> to be established when under attack, but at the cost the attacker
> has to pay, one might even say that this is not even a serious
> threat.

Making the user to do user interaction by simply sniffing one packet
from the air, and forwarding it to the right server is very cheap way
to annoy people...

For users point of view it does not even look he is under attack, he
just sees that this crappy network again requires him to
reauthenticate at random times. Note, that he does not blame the
attacker's network, as he didn't detect anything there. The attack can
have happened hours before, and then when he finally comes to the home
WLAN network, or some other network which actually works, he sees that
he needs to reauthenticate. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

[Tero Kivinen]

Matthew Cini Sarreo writes:
> You still need the IDr and AUTH payloads in the reply. This is needed as
> INVALID_SYNTAX is authenticated and encrypted.

INVALID_SYNTAX is fatal error meaning that other end didn't follow the
protocol specification, and the IKE SA is going to be removed anyways,
and there is not really point of putting AUTH payload there (it can be
there, but there is no need).

If the other end is not following protocol specification (i.e. is
non-complient), there is not really point of trying to be nice. This
is something that cannot be seen by normal customers ever, it should
only be seen by the implementors when they are testing against broken
implementations.

So better just send error message back as it is easiest for your
implementation (i.e. if it is easy to include AUTH etc to the error
message, then do so, if not, then leave them out). 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Lakshminath Dondeti writes:
> When did MOBIKE come into picture?  What are you saying Tero, that IPsec 
> session resumption is an alternative to MOBIKE and a slow one at that?

Yes.

Both solve the same problem that IKE SA recovers from the IP-address
change, or switching from one network to another (i.e. from cellular
to WLAN).

I do not really see any fundamental reason why the IKE SA needs to be
taken down when in cellular. I can see reasons why it might not be
needed, but the IKE SA could still be kept up and running, and if done
that way, then MOBIKE will offer solution how to move the IKE SA to
the new network, and it will mostly do it in 1 RT.

> "Annoy" being the keyword.  I am now more convinced that we are really 
> making the protocol inefficient because some kid might try to annoy some 
> people some time.  To counter such potential annoyances which may not 
> happen at any frequency that matters, we are going to sacrifice the user 
> experience all the time?

I am saying we are not sacrificing the user experience in any
noticeable way even if we do 2 RT protocol. I expect that 99.999%
users will never notice whether the 1 RT or 2 RT protocol was used if
there is no attack. On the other hand, 100% users will notice the
attacks if 1 RT protocol is used, and 0% of users will notice the
attacks if 2 RT protocol is used.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Lakshminath Dondeti writes:
> MOBIKE assumes that the other side has state, correct?

Yes. 

> Session resumption has to do with providing that state. How are they
> the same?

In this example given (handover from cellular to wlan, without
breaking existing phone call), I do not really see any point why the
IKE SA state needs to be removed from the server side, and as such I
think the much better solution is to use MOBIKE and keep IKE SA up all
the time.

As I do not have any idea where people want to use the resumption, I
have VERY HARD time to justify the different protocol options. But
anyways one of the things required is that it "shall not have negative
impact on IKEv2 security features", and I think 1 RT protocol will
have negative impact to security features.

> Under attack, the protocol stretches to 3 RTs.

3 RT + Diffie-Hellman + public key operation + user interaction to
type in password or securid token etc.

> So, you are saying that there is no noticeable difference between 1
> and 2 RTs, but there is between 2 and 3? Is your point that the DH
> computation will be noticed?

With group 18: yes... With typing in the passphase to do
reauthentication with RSA token card : yes. With digging out your
securid card and typing in pin, and typing in the next token to the
prompt: yes.

> My point is that we'd beyond the real-time budgets after 1 RT
> anyway.

You should not really do break-before-make style of transitions on
real-time environments, and if you keep the old connection while
making the new one, then this whole issue is non-issue.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Narayanan, Vidya writes:
> Somehow, we in the IETF think that we can make decisions for other
> standards bodies, especially ones that do real deployments.  I don't
> know how we can say things like they should always use the IKE SA
> whether they need it or not - there can be several reasons not to
> use it when they don't need it, including how some VPN vendors may
> charge.

It is impossible for IETF to think about those other standard bodies,
as we do not know what they plan to do. I have several times tried to
get people to explain me the use case for which this protocol has been
aimed for, so I could think whether some specific attack or
optimization is suitable or not, but as only reply I have received is,
that it is outside the scope of this discussion, then there is really
no point of blaming people for making decisions for other standard
bodies. What else can we do?

Nobody has still explained me why the 1 RT protocol is required for
those other standard bodies, and why should the security of this
protocol be weaker because of the requirements from those other
unknown standard bodies.

> Also, mobility may need to be handled by MIP6 and we know that it
> doesn't co-exist with MOBIKE.

That is news for me. One of the reasons MOBIKE was created was to
allow it to be used as building block for Mobile IP. So why does not
MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could
be used by Mobile IP, and there were Mobile IP people taking part in
the specification process back then.

So what is the exact problem there?

I am thinking it might not be worth of standardizing the resumption at
all, if we for that again hear 3 years after we finished the work that
it cannot be used because of some unspecified reason.

> I'm also further intrigued by this attack we are so passionately
> discussing - the motivation for the attacker here is to annoy other
> users?

Almost all DoS attacks are only there to annoy the users. If someone
uses DoS attack to bring some web server or dns-name server or similar
down for few hours, that is just annoying users. Everything will work
again when the attacks stops, and might even work during the attack
but access might be much slower than normally.

> Surely, the attacker gets nothing meaningful in return - I
> simply can't see how the risk of such an attack can be anywhere
> close to even medium - it is barely low in my view.

Most of the DoS attackers are not wanting to get something meaningful
in return. I still think we need to design protocols so they are
secure against such attacks.

And it is not only against protecting against the attacks, this is
also against normal working of the protocol. I.e. if sending one
packet whose response packets gets lost, can destroy state from the
server, in such way that client cannot detect that, and needs to start
IKE SA creation from the beginning, I consider even that a big
problem.

When we were specifying the MOBIKE we made sure it works also in cases
where some of the network connections are one-way, i.e. no return
packets get back. It consideres such links broken, and does not use
them. This was considered important to get it right, because in that
environment it was seen that quite often the links it might see might
have such unidirectional properties, and the whole protocol cannot be
broken because of one such link.

With resumption the whole protocol breaks down if such unidirectional
link is ever tried to be used.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[Tero Kivinen]

Lakshminath Dondeti writes:
> > You should not really do break-before-make style of transitions on
> > real-time environments, and if you keep the old connection while
> > making the new one, then this whole issue is non-issue.
> Good advice, but that consensus process is from elsewhere.  Not every 
> device has multiple interfaces, not every architecture implements the 
> idea of multiple simultaneous associations with base stations, and so on.

We were discussing moving traffic from "secure" cellular network
(which do not require IPsec protection, and IKE SA was suspended
because of that) to "unsecure" WLAN network (which now requires IPsec
protection because it is unsecure). Do you really say some device
which can talk to both WLAN and cellular network cannot talk to both
of them simultaneously?

Even with if they cannot be used simultaneously they can still bring
the IKE SA up while using the cellular network, and then use MOBIKE to
move the already up and resumed IKE SA from cellular to WLAN.

It seems there is again some scenarios you are refering to that I do
not know about, as I do not really think you are now talking about the
same use case anymore. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Reopening issue #12

[Tero Kivinen]

Paul Hoffman writes:
> It was pointed out that (a) this is a new MUST and

Yes, but it can mostly be already deducted from the requirement that
end node cannot violate its own policy, meaning it needs to delete
Child SA which are not following his policy. If that is already done,
there is no point for the new SA having narrower scope than old SA
had, and making this MUST makes it simplier for implementations (i.e.
they do not need to think what to do for the traffic which do not fit
the rekeyed SA, and we do not need to add the traffic selectors from
the packet parts). 

> (b) this also
> assumes that the encryption algorithm and so on will be the same. 

No it does not. I do not see any text there saying anything about
encryption algorithms. Those are negotiated as normally and again if
policy has been changed so that the original algorithms are not valid
anymore, then the child SA should have been deleted already.

There are cases where intiator can only propose subset of algorithms
it itself finds acceptable, but that will simply result in
NO_PROPOSAL_CHOSEN failure, if other end does not accept any of the
algorithms initiator offered. 

> So, how does the WG want to proceed here?

I do not think we need to do anything more than what is already done
here. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08

[Tero Kivinen]

Section 3 says:

   The gateway MUST include the nonce data from the Ni payload sent by
   the initiator in the REDIRECT payload.  This prevents certain Denial-

but the figures showing how redirect is done does not include Ni data
in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it is
bit misleading to use IP_R in the payload, perhaps New_GW_ID would be
better. I.e. it would be better to write the reply as:

  (Initial_IP_R:500 -> IP_I:500)
  <-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)

Similar change is also needed in later sections too.

---

In section 5 it should be:

   <--  HDR, SK {N(REDIRECT, New_GW_ID,)}

(also changed the N[] to N() as is used normally).

---

In section 6 it should be:

  (IP_R:500 -> IP_I:500)
  <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
   N(REDIRECT, New_GW_ID,)}

(Again changed the N[] to N()). This section does not say whether the
Ni is included in the response, but I assume it is omitted as there is
no need for it. This section should make it clear whether it is
included or omitted.

---

In section 6 the text:

   In such cases, the gateway should send the REDIRECT notification
   payload in the final IKE_AUTH response message that carries the AUTH
   payload and the traffic selectors.  The gateway MUST NOT send and the
   client MUST NOT accept a redirect in an earlier IKE_AUTH message.

is bit confusing. First it says the gateway (lowercase) should send
REDIRECT in final IKE_AUTH response that carries the AUTH payload and
traffic selectors. Then it says that gateway MUST NOT send redirect in
earlier messages.

Firstly the final IKE_AUTH response willnot include the traffic
selectors, as they are omitted if client is redirected. Thus it is
misleading to say "that carries the AUTH payload and traffic
selectors".

Secondly, it is not clear whether the "In such cases" only refers to
the cases wher gateway decides to do something (interact with AAA
server/ use external authentication server), or in all cases where EAP
or multiple authentication is used. If it is in all cases where EAP or
multiple authentication is used, then that means gateway cannot
redirect in first IKE_AUTH (which is fine for me, but I am not sure if
that was meant). If it is only when gateway needs AAA/external
authentication server, then how can client enforce the "MUST NOT
accept redirect in an earlier IKE_AUTH message", if it does not know
whether gateway needs to consult external authentication server or AAA
server...

In general the text is so confusing that I am not sure what is meant.
One easy way to solve this problem is to say things clearly, i.e.
either add one of the following texts:

  If multiple IKE_AUTH exchanges are used the REDIRECT notification
  payload MUST be in the IKE_AUTH response from gateway to the client,
  which also includes the gateways AUTH payload. With EAP, there is
  two possible places (first IKE_AUTH and last IKE_AUTH). With
  multiple authentication support there are AUTH payload after each
  authentication finished, thus server can redirect after each
  authentication step is finished. REDIRECT notification MUST NOT be
  sent or accepted in any other messages than those having AUTH
  payload. 

or

  If multiple IKE_AUTH exchanges are used the REDIRECT notification
  payload MUST be in the final IKE_AUTH response from the gateway to
  the client, i.e the one that contains the AUTH payload, and that
  would also contain the Child SA SA payload and traffic selectors,
  if connection would not have redirected. REDIRECT notification MUST
  NOT be sent or accepted in any of the earlier IKE_AUTH messages. 

---

In section 7.2 the first paragraph says that "The message includes the
new responder's IP address.", but this payload can also include FQDN,
I think it should be changed to "The message includes the
new responder's IP address or DNS name.". 

---

In section 7.2. the GW Identity Type should be made to be IANA
allocated registry. We have already had all kind of problems when we
have such registries which are not clearly defined, and then someone
wanted to add entries to there.

It would also be good to explicitly say that IPv4 address are encoded
as 4 octects, and IPv6 addresses are encoded as 16 octets, and that
the FQDN of the new VPN gateway is encoded as dns name without any
terminators (e.g., NUL, CR, etc). Perhaps it would be good to
cut & paste the similar parts from the section 3.5 of the rfc4306. 

---

In section 7.3 it is not clear whether this registry used for GW Ident
Type is same as in section 7.2 or not. As it does not have same
values, I assume it is supposed to be separate registry. In that case
it would be better to use some different name for it, so there is no
confusion which registry is used (for eaxmple "Original GW Ident
Type").

As a separate registry i