Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02

[Daniel Migault]

Hi Tero,

Thanks for the response. Version 4 of the draft has been updated with this
alternative.

Yours,
Daniel

On Thu, May 10, 2018 at 10:53 AM, Tero Kivinen  wrote:

> Daniel Migault writes:
> > another alternative could be:
> >
> > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
> >used, Implicit IV as described in this document MUST NOT be used in
> >setups with the chance that the Sequence Number overlaps for one SA.
> >Multicast as described in [RFC5374], [RFC6407] and
> >[I-D.yeung-g-ikev2] is a prominent example, where many senders share
> >one secret and thus one SA.  As
> >such, it is NOT RECOMMENDED to use Implicit IV with Multicast.
>
> I would actually prefer to this. I think it is better to say don't do
> it, than provide ways it could be done before saying don't do it
>
> I.e., if someone is interested in this then we need to write new
> specification that will specify how it is done, so there is no point
> of speculating here what it could be.
> --
> kivi...@iki.fi
>
> ___
> 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

[IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of 
the IETF.

Title   : Implicit IV for Counter-based Ciphers in 
Encapsulating Security Payload (ESP)
Authors : Daniel Migault
  Tobias Guggemos
  Yoav Nir
Filename: draft-ietf-ipsecme-implicit-iv-04.txt
Pages   : 7
Date: 2018-05-10

Abstract:
   Encapsulating Security Payload (ESP) sends an initialization vector
   (IV) or nonce in each packet.  The size of IV depends on the applied
   transform, being usually 8 or 16 octets for the transforms defined by
   the time this document is written.  Some algorithms such as AES-GCM,
   AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do
   not require an unpredictable nonce.  When using such algorithms the
   packet counter value can be used to generate a nonce.  This avoids
   sending the nonce itself, and saves in the case of AES-GCM, AES-CCM,
   AES-CTR and ChaCha20-Poly1305 8 octets per packet.  This document
   describes how to do this.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-04
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [IPsec] PLMTUD probes for IPsec

[Paul Wouters]

On Thu, 10 May 2018, Shibu wrote:


PMTUD over IKE is needed anyways for large IKE cert payloads


I don't agree. We can handle these with fragmentation now just fine.


However, one caveat with above approach is that there is an implicit assumption 
that paths for control and data traffic 
are same (i.e. IP based, 3 tupple paths).
With SDWAN use cases (wherein paths could be orchestrated based on proto, port, 
QoS, App ID etc), would it be a precise 
assumption to make? How would we handle these cases when the paths are build 
for ESP and IKE differently?


Right. UDP 4500 packets not starting with 4 zero bytes could be handled
differently.

Paul

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

Re: [IPsec] PLMTUD probes for IPsec

[Michael Richardson]

Shibu  wrote:
> PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do
> PMTUD over IKE,  we could depend upon the same discovered MTU value for 
ESP
> paths as well as a guidance value. This seems to work for most of the
> cases, and there seems to be interest in the group towards this option. So
> this looks to be a good option overall, if we tackle IKEv2 window nuances
> effectively.

I agree.  This handles 90% of the cases, except for bigger more nuanced 
environments.

> However, one caveat with above approach is that there is an implicit
> assumption that paths for control and data traffic  are same (i.e. IP
> based, 3 tupple paths).
> With SDWAN use cases (wherein paths could be orchestrated based on proto,
> port, QoS, App ID etc), would it be a precise  assumption to make? How
> would we handle these cases when the paths are build for ESP and IKE
> differently?

I suggest that in such a situation, that *IKE* negotiate (probably just
Notify's to announce actually) the existence of a TCP endpoint that is within
the tunnel, and do PLMUTD over TCP across that to test things.

In some situations the IKE daemon would be able to do the connection attempt
itself, but in other situations, some other entity might have to do this.
Much of this is a local implementation problem only the Notify needs to be
standarized.
There might be IPv6 sockets API extensions that might be desired to get TCP
MTU information out the kernel, but that's not ipsecme's problem :-)

The IKE then needs to update the ESP machinery to know what the MTU of the
inside of the tunnel appears to be, and it should generate ICMPs if it's
bigger.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 








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

Re: [IPsec] PLMTUD probes for IPsec

[Tero Kivinen]

Shibu writes:
> With SDWAN use cases (wherein paths could be orchestrated based on proto,
> port, QoS, App ID etc), would it be a precise  assumption to make? How would
> we handle these cases when the paths are build for ESP and IKE differently?

If the ESP and IKEv2 packates do not follow the same path, then it is
possible that the ESP path is broken, and when we run the test over
IKEv2 path to see whether connection is broken or not, we do get
result that it works, even when ESP does not.

Because of this I would say that every SDWAN implementation should try
to make sure that all ESP and IKEv2 packets do use the same path as
otherwise there might be black holes, or repeated tearing down SAs and
recreating them (i.e., if ESP works but IKEv2 does not).

In case someone still makes implementation which does that, then IKEv2
can use UDP encapsulation and then both IKEv2 and ESP packets do
follow same path.

I.e., try to avoid those, or if you make them, make sure they have
same PMTU, and if you cannot ensure that, enable UDP encapsulation in
IPsec... 
-- 
kivi...@iki.fi

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

Re: [IPsec] PLMTUD probes for IPsec

[Shibu]

Hello Tero and all,

We discussed internally among the authors and it looks there exist 3
choices - to do PMTUD  over IKE, or ESP or both. (Many reviewers have
already pointed out these at various stages, just collating them here).

PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do
PMTUD over IKE,  we could depend upon the same discovered MTU value for ESP
paths as well as a guidance value. This seems to work for most of the
cases, and there seems to be interest in the group towards this option. So
this looks to be a good option overall, if we tackle IKEv2 window nuances
effectively.

However, one caveat with above approach is that there is an implicit
assumption that paths for control and data traffic  are same (i.e. IP
based, 3 tupple paths).
With SDWAN use cases (wherein paths could be orchestrated based on proto,
port, QoS, App ID etc), would it be a precise  assumption to make? How
would we handle these cases when the paths are build for ESP and IKE
differently?

Thanks,
Shibu.


On Fri, Apr 13, 2018 at 1:48 PM, Tero Kivinen  wrote:

> Ron Bonica writes:
> > In 99.9% of cases you are probably correct. If there is an ECMP
> > between the encrypting node and the decrypting node, all ECMPs have
> > the same PMTU.
>
> Is it 99.9%, or 99.%?
>
> > And because this is true in such a vast majority of cases, none of
> > us have seen a situation where one ECMP has a larger PMTU than then
> > next.
>
> If none has not yet been seen it is much closer to 100% than 99.9%.
> Depending of course how many setups people have seen...
>
> > However, we still need to be prepared for that rare situation where
> > one ECMP does have a greater PMTU that the next. Although black
> > swans are rare, they bite very hard!
>
> There is also option to say that network is so broken that we fall
> back to IPsec over TCP, and in that case both ESP and IKE packets go
> inside same TCP stream and MTU discovery is done simlarly for both, so
> things work. I.e., that might be acceptable solution for those rare
> really broken cases.
> --
> kivi...@iki.fi
>
> ___
> 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] Comments about draft-ietf-ipsecme-implicit-iv-02

[Tero Kivinen]

Daniel Migault writes:
> another alternative could be:
> 
> As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
>    used, Implicit IV as described in this document MUST NOT be used in
>    setups with the chance that the Sequence Number overlaps for one SA.
>    Multicast as described in [RFC5374], [RFC6407] and
>    [I-D.yeung-g-ikev2] is a prominent example, where many senders share
>    one secret and thus one SA.  As
>    such, it is NOT RECOMMENDED to use Implicit IV with Multicast.

I would actually prefer to this. I think it is better to say don't do
it, than provide ways it could be done before saying don't do it

I.e., if someone is interested in this then we need to write new
specification that will specify how it is done, so there is no point
of speculating here what it could be.
-- 
kivi...@iki.fi

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