[IPsec] RFC8229 (IKE over TCP) and retransmissions

[Tero Kivinen]

[WG chair hat off]

Valery Smyslov writes:
> TCP provides reliable transport, so there is no need for application to 
> deal with retransmissions. Moreover, performing retransmissions by IKE 
> in case of TCP on congested networks could further increase congestion 
> and degrade performance. For this reason IKE initiator SHOULD NOT
> retransmit requests if they are sent over TCP. However, IKE responder 
> MUST 
> correctly handle retransmitted request messages received over TCP, but 
> it SHOULD NOT resend response messages in this case.

I think such text should have been added to the RFC8229. 

> I think not having such a recommendation in RFC8229 is an oversight.
> I'm not sure though it's worth filling in errata... What the WG thinks?

I am not sure if it would be enough to make errata, I would actually
think it might be better to make RFC8229bis to fix this issue. The
problem with errata is that there are lots of people who do not notice
it...

So I think you should make errata of it, and we most likely should
make new version of 8229 and add that text, but that is just my
personal view of the issue.
-- 
kivi...@iki.fi

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

Re: [IPsec] PLMTUD probes for IPsec

[Ron Bonica]

Folks,

In the first version of this draft, we leveraged IKE to exchange messages. And 
provided with a good enough reason, we might go back to that position!

We moved away from IKE for the following reasons:

- The path between the encrypting and decrypting nodes might include ECMP. If 
so, IKE messages might take a different path than actual encrypted data
- The current method provides the same level of protection as IKE and possibly 
better performance
- The current doesn't require changes to IKE

Are these reasonable assumptions. If not, we would be happy to return to the 
IKE solution.

   Ron


> -Original Message-
> From: Michael Richardson 
> Sent: Thursday, April 5, 2018 11:09 AM
> To: Valery Smyslov 
> Cc: ipsec@ietf.org; Ron Bonica 
> Subject: Re: [IPsec] PLMTUD probes for IPsec
> 
> 
> Valery Smyslov  wrote:
> >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica
> >> > https://datatracker.ietf.org/meeting/101/materials/slides-101-
> ipsecme-packetization-layer-path-mtu-
> >> discovery-01
> >>
> >> > Problem: IPsec Tunnel has an PMTU as any other tunnel.
> >> > Solution in Transport Area: Inband Path discovery
> >>
> >> I spoke to Ron afterwards, and I'm very enthusiatic about getting
> PLPMTUD
> >> widely deployed.  We didn't get to this slides, so we didn't figure
> >> out what he needs. Slides talk about an IP-level probe that IPsec
> >> encapsulators can use to get estimate for tunnel inner MTU.
> 
> > Why IKE messages cannot be used for this purpose?
> 
> I think that possibly it can, and this is the kind of discussion that
> I think we should have.   The advantage of doing that is that it requires
> no new code on the responder!  That's a big win for deploying.
> It means that this can be done unilaterally, no new specification, just
> implementation advice.
> 
> The slight implementation challenge is making sure that the IKE traffic is 
> going
> along the same path as the ESP traffic.  I'd like to hear from Ron about
> whether this is an issue.
> 
> I also thought about using having some plpmtud on each end make a TCP
> connection *within* the tunnel and use the already defined plpmtu for TCP.
> That might be really easy for systems without user/kernel divisions (some
> router kernels). It would require some notifications to indicate that the
> responder has a TCP port open.  And of course, the traffic would have to fit
> into the tunnel as well.
> 
> 
> 
> 
> > Regards,
> > Valery.
> 
> >> But, if we can get PLMTUD deployed for all traffic, then the end-nodes
> can
> >> do appropriate PMTU probing and can figure out what the inner MTU is.
> >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most
> >> systems, which has been left in the off state because of lack of
> evidence
> >> that it isn't harmful.
> >>
> >> There seems to be some sticking points among the high-speed about
> CDNs:
> >> they hate all PMTUD as it screws with tx scheduling into hardware.
> >> (TCP segment offload issues)
> >>
> >> So they just use 1280 is what I was told.  That's good for the network,
> but
> >> it removes them as strong allies for getting PLPMTUD enabled by
> default
> >> everywhere.   It would be nice if we could get a BCP out of them. Such
> >> BCP could also bless PLPMTUD for everyone else.  I was pushing for this
> >> with RFC8200/STD86 but there was insufficient evidence of
> deployment.
> >>
> >> --
> >> Michael Richardson , Sandelman Software
> Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> 
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

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

Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions

[Tommy Pauly]

Hi Valery,

Thanks for bringing this up with the WG!

I agree that retransmissions of IKE packets within the TCP stream may be 
pointless, and add to congestion. We do mention this for ESP packets over the 
TCP stream (Section 12.2 Added Reliability for Unreliable Protocols), but it 
doesn’t call out IKE specifically.

Depending on how TCP encapsulation is implemented on each peer, it may be safe 
to assume that the entire end-to-end communication is reliable, but it may not 
be. In our testing of the protocol, we have placed boxes in front of IKEv2 
responders that handle the TCP encapsulation and translate them into UDP 
packets to pass on to the vanilla IKEv2 responder. In this case, the end-to-end 
reliability can’t be guaranteed, and the initiator of a message then may still 
need to retransmit IKE packets.

If we did want to add a recommendation here, I’d be tempted to say that an 
implementation should certainly be less aggressive with retransmissions in IKE, 
but may still send them if there is a lack of response from the remote peer. 
I’m not overly concerned with the impact of retransmitting IKE packets on the 
stream to overall tunnel performance, since these generally only account for a 
few packets.

Thanks,
Tommy

> On Apr 5, 2018, at 6:10 AM, Valery Smyslov  wrote:
> 
> Hi Tobias,
> 
>> Hi Valery,
>> 
>> I agree that generally retransmits are not useful or needed with TCP
>> encapsulation.  But as I see it, retransmits might actually be required
>> in some situations.  If the client sends e.g. a CREATE_CHILD_SA request
>> but the TCP connection is closed or gets unusable for some reason before
>> the server's response is received, the client has to reestablish the TCP
>> connection.  And the only way to do this (with window size 1, so no DPD
>> or MOBIKE update can be sent) is to send a retransmit of the already
>> sent message (otherwise the server might not know which TCP connection
> 
> That's why I suggested SHOULD :-)
> 
>> to use to send the CREATE_CHILD_SA response - I guess ESP packets could
>> be used for that too, if there are any and there is a way to get
>> notified in userland).  On the other hand, RFC 8229 explicitly says that
>> a responder should not consider retransmitted messages when deciding
>> which TCP connections should be used...so I guess there is no way to
>> recover properly if the TCP connection is severed mid-exchange (e.g.
>> because a NAT device is rebooted or the client device roams between
>> networks).
> 
> Yes, there may be situations which are difficult to recover from...
> 
> Regards,
> Valery.
> 
>> Regards,
>> Tobias
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

Re: [IPsec] PLMTUD probes for IPsec

[Michael Richardson]

Valery Smyslov  wrote:
>> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica
>> > 
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-
>> discovery-01
>>
>> > Problem: IPsec Tunnel has an PMTU as any other tunnel.
>> > Solution in Transport Area: Inband Path discovery
>>
>> I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD
>> widely deployed.  We didn't get to this slides, so we didn't figure
>> out what he needs. Slides talk about an IP-level probe that IPsec
>> encapsulators can use to get estimate for tunnel inner MTU.

> Why IKE messages cannot be used for this purpose?

I think that possibly it can, and this is the kind of discussion that
I think we should have.   The advantage of doing that is that it requires
no new code on the responder!  That's a big win for deploying.
It means that this can be done unilaterally, no new specification,
just implementation advice.

The slight implementation challenge is making sure that the IKE traffic
is going along the same path as the ESP traffic.  I'd like to hear from
Ron about whether this is an issue.

I also thought about using having some plpmtud on each end make a TCP
connection *within* the tunnel and use the already defined plpmtu for
TCP.  That might be really easy for systems without user/kernel divisions
(some router kernels). It would require some notifications to indicate that
the responder has a TCP port open.  And of course, the traffic would
have to fit into the tunnel as well.




> Regards,
> Valery.

>> But, if we can get PLMTUD deployed for all traffic, then the end-nodes 
can
>> do appropriate PMTU probing and can figure out what the inner MTU is.
>> i.e. just get everyone to enable plpmtu (4821). It's a knob on most
>> systems, which has been left in the off state because of lack of evidence
>> that it isn't harmful.
>>
>> There seems to be some sticking points among the high-speed about CDNs:
>> they hate all PMTUD as it screws with tx scheduling into hardware.
>> (TCP segment offload issues)
>>
>> So they just use 1280 is what I was told.  That's good for the network, 
but
>> it removes them as strong allies for getting PLPMTUD enabled by default
>> everywhere.   It would be nice if we could get a BCP out of them. Such
>> BCP could also bless PLPMTUD for everyone else.  I was pushing for this
>> with RFC8200/STD86 but there was insufficient evidence of deployment.
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>



--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] PLMTUD probes for IPsec

[Valery Smyslov]

Hi Paul,

> > Why IKE messages cannot be used for this purpose?
> 
> IKE messages might not take the same path, eg ESP goes through hardware
> offload or other things, or intermediary routers might have different
> rules for UDP vs ESP.

True, unless UDP encapsulation is used...

Regards,
Valery.

> Paul

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

Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions

[Tobias Brunner]

Hi Valery,

I agree that generally retransmits are not useful or needed with TCP
encapsulation.  But as I see it, retransmits might actually be required
in some situations.  If the client sends e.g. a CREATE_CHILD_SA request
but the TCP connection is closed or gets unusable for some reason before
the server's response is received, the client has to reestablish the TCP
connection.  And the only way to do this (with window size 1, so no DPD
or MOBIKE update can be sent) is to send a retransmit of the already
sent message (otherwise the server might not know which TCP connection
to use to send the CREATE_CHILD_SA response - I guess ESP packets could
be used for that too, if there are any and there is a way to get
notified in userland).  On the other hand, RFC 8229 explicitly says that
a responder should not consider retransmitted messages when deciding
which TCP connections should be used...so I guess there is no way to
recover properly if the TCP connection is severed mid-exchange (e.g.
because a NAT device is rebooted or the client device roams between
networks).

Regards,
Tobias

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

Re: [IPsec] PLMTUD probes for IPsec

[Paul Wouters]

On Thu, 5 Apr 2018, Valery Smyslov wrote:


Why IKE messages cannot be used for this purpose?


IKE messages might not take the same path, eg ESP goes through hardware
offload or other things, or intermediary routers might have different
rules for UDP vs ESP.

Paul

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

[IPsec] RFC8229 (IKE over TCP) and retransmissions

[Valery Smyslov]

Hi,

after re-reading RFC8229 several times I cannot find any language about
retransmitting IKE messages in case of TCP. Clearly, the behavior described
in Section 2.1 is wrong in case of TCP, since TCP provides a reliable transport.
Blindly following these recommendations would only make things worse,
in case of network congestion, since it increases the amount of data TCP
would try to resend, and thus increasing congestion even more.
Ideally, some text should have been added, similar to the text clarifying
using IKE fragmentation in case of TCP. Something like that:

TCP provides reliable transport, so there is no need for application to 
deal with retransmissions. Moreover, performing retransmissions by IKE 
in case of TCP on congested networks could further increase congestion 
and degrade performance. For this reason IKE initiator SHOULD NOT
retransmit requests if they are sent over TCP. However, IKE responder MUST 
correctly handle retransmitted request messages received over TCP, but 
it SHOULD NOT resend response messages in this case.

I think not having such a recommendation in RFC8229 is an oversight.
I'm not sure though it's worth filling in errata... What the WG thinks?

Regards,
Valery.

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

Re: [IPsec] PLMTUD probes for IPsec

[Valery Smyslov]

Hi Michael,

> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica
> > 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-
> discovery-01
> 
> > Problem: IPsec Tunnel has an PMTU as any other tunnel.
> > Solution in Transport Area: Inband Path discovery
> 
> I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD
> widely deployed.  We didn't get to this slides, so we didn't figure
> out what he needs. Slides talk about an IP-level probe that IPsec
> encapsulators can use to get estimate for tunnel inner MTU.

Why IKE messages cannot be used for this purpose?

Regards,
Valery.

> But, if we can get PLMTUD deployed for all traffic, then the end-nodes can
> do appropriate PMTU probing and can figure out what the inner MTU is.
> i.e. just get everyone to enable plpmtu (4821). It's a knob on most
> systems, which has been left in the off state because of lack of evidence
> that it isn't harmful.
> 
> There seems to be some sticking points among the high-speed about CDNs:
> they hate all PMTUD as it screws with tx scheduling into hardware.
> (TCP segment offload issues)
> 
> So they just use 1280 is what I was told.  That's good for the network, but
> it removes them as strong allies for getting PLPMTUD enabled by default
> everywhere.   It would be nice if we could get a BCP out of them. Such
> BCP could also bless PLPMTUD for everyone else.  I was pushing for this
> with RFC8200/STD86 but there was insufficient evidence of deployment.
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 


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

Re: [IPsec] initiator privacy vs responder stealth

[Valery Smyslov]

Hi Michael,

> > IKE_SA_INIT privacy concerns - David Schinazi
> > 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2-
> ike-sa-init-exchange-00
> 
> > Concerns around privacy of the peers (who the initiator is, and if the
> > responder is running IKE)
> 
> I think that we had some consensus that we should split the document into two
> problem statements.  Protecting the initiator identity against MITM attackers
> can be solved a whole bunch of ways.  A zero-knowledge proof would seem to
> be a better way to start to me.
> 
> The problem of making the IKE responders stealthed seems like a different
> problem entirely.

+1.

Regards,
Valery.

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

Re: [IPsec] use of IKE_AUX vs rekey of IKE Parent SA in draft-smyslov-ipsecme-ikev2-aux

[Valery Smyslov]

Hi Michael,

> > Michael R.:
> > - doesn't seem to be generic cause of the re-key.
> > - why not do a re-key after IKE_AUTH
> > - As DH is broken, this approach does not seem to protect it.
> 
> I suggested in the mic line that the use of IKE_AUX seemed to introduce more
> issues than it solved.  It must defend against all the various attacks which
> IKEv2 already defends against today.

Please, elaborate, where do you think it fails to do this.

> Instead we should do some kind of IKE_AUTH round trip (without CHILDSA)
> with "classic" authentication methods, and using "classic" DH methods.
> Then use RFC7383 to get the larger QM exponents across, and then do
> a IKE_AUTH "rekey" to switch to the QM exponents.
> 
> This just feels cleaner to me.

I can see some issues with this approach.

First, currently there is no such thing as "IKE_AUTH rekey". IKE SA rekey via 
CREATE_CHILD_SA doesn't perform authentication of the peers. So, you need 
to modify protocol to add an additional authentication exchange after IKE SA 
is created. This is more serious modification than introducing IKE_AUX.
Then, if you perform authentication twice (first with "classic methods"
and then some kind of post-authentication) then you need to have
two sets of credentials for the peers, or use AUTH_NULL in the
initial IKE_AUTH. The former is problematic from operation point
of view (see Section 5.2 of draft-ietf-ipsecme-qr-ikev2), the latter increases 
vulnerability to DoS attacks (see Section 10 of RFC8019). Third, your proposal 
adds more round trips and require more CPU resources (to perform
additional authentication).

> This would work far better today as it would resist all sorts of resource
> exhaustion attacks that we currently defend easily against.  

Not exactly, please see above.

> Of course, the way that we defend against them today is by use of DH methods 
> and
> authentication methods that might be defeated by quantum computers.
> 
> So the question becomes: in a post-QM world, do we think that the attackers
> will be able to defeat our pre-QM methods in real time and thus attack us?
> If the answer is no, then I think that we can use this multi-level security
> mechanism to advantage.
>
> If the answer is yes (they can decrypt in real time), then we need to build
> all the fragmentation protections into IKE_AUX anyway.

If an attacker is equipped with a QC that can break initial (EC)DH in real time,
then he/she will know the keys for the IKE_AUX and thus can modify
its content and send bogus packets. However, this modification will be detected 
in the IKE_AUTH if auth method used is QC-safe (like hash based 
signatures). Cryptographers tell us that PQ authentication is much 
more well studied than PQ key exchange and that they are pretty sure in 
security 
of such schemes. I see no reason why these schemes cannot be used
even in the current IKEv2, so I presume that even if an attacker breaks
initial DH in the IKE_SA_INIT, it will be detected. So, the only real
benefit the attacker gets in this case is that he/she can mount DoS
attack, so in this regard the IKE_AUX is no worse than performing
fragmentation in the IKE_SA_INIT. Moreover, in this case your proposal
will be vulnerable as well (an attacker breaks classic (EC)DH and 
modifies IKE_AUTH messages; if it is also breaks classic auth, 
then DoS attacks would be even worse than in case of IKE_AUX).

And I hope that by the time the attacker can break classical (EC)DH in real 
time, some 
PQ key exchange schemes with relatively small public key would appear, so that 
we could
replace classical (EC)DH with one of such scheme. There is no need
that this scheme be super-secure (since more PQ exchanges
can be done in IKE_AUX) , it's enough if it withstands breaking in real time
having relatively small public key.

Regards,
Valery.

> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-

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