On Thu, 14 Sep 2017, Mike Sullenberger (mls) wrote:
If you want to securely encrypt traffic between endpoints then you are going to
need to build point-point encrypted tunnels
between these endpoints, this is the main reason that SD-WAN implementations
use either a full-mesh or dynamic-mesh of
On Fri, 15 Sep 2017, Michael Richardson wrote:
Paul Wouters wrote:
> See also Opportunistic IPsec, which is a way of creating a mesh with
> IPsec using some kind of central (X.509) or decentral (DNSSEC)
> authentication. See:
And it's important to note that the rever
On Fri, 15 Sep 2017, Michael Richardson wrote:
> Right. But also we support the forward DNS. That is libreswan can also
> use the IDr for a forward DNS lookup, which can also be an internal-only
> zone. I believe in that case we also then do another lookup of the IDr
> in the forward
On Mon, 18 Sep 2017, Linda Dunbar wrote:
If we need to use IPsec tunnels to connect a group of CPE devices, (as shown in
the figure I sent earlier), do you still need DNS? Or the Key
management will be managed by the "Zero Touch Deployment Service" in the figure
below?
You can use any protoc
On Thu, 28 Sep 2017, Tero Kivinen wrote:
The original draft-ietf-ipsec-ciph-aes-gcm [1] had four differnet ICV
lengths: 4, 8, 12, and 16 octets, and they got numbers for all of them
[2]:
Ahh, so that's where it came from :)
for 8, 12, 16 octet versions came to be 18, 19, and 20, and the numb
On Fri, 29 Sep 2017, Valery Smyslov wrote:
Adding IKE-level fragmentation to the process adds an additional place
that DDoS attacks can hit.
We have DDoS protection mechanisms. I think it's possible to define
IKE_SA_INIT fragmentation so that these mechanisms be still able to work.
Th
Did it not get marked as replacing the fluhrer draft ? Now there is no diff
available. Can that still be fixed?
Sent from my iPhone
> On Oct 19, 2017, at 17:59, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft
On Thu, 26 Oct 2017, Tero Kivinen wrote:
In last IETF we had people with items which we could add to charter,
so I want those people wanting to add things to charter to send an
email to the mailing list about what items they would like to propose
to the charter, and preliminary charter text for
On Sat, 28 Oct 2017, Hu, Jun (Nokia - US/Mountain View) wrote:
[HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange
Protocol Version 2 (IKEv2)) can't be used for this purpose?
The problem with IKE Redirect is that it requires IKE SA to be re-established
from scratch.
It consumes
On Wed, 23 Aug 2017, Valery Smyslov wrote:
It is a good idea. A new optional notification that includes the auth_data as
it would be calculated without the
PPK would work. With that, the corner case of ' PPK_id configured on initiator
but missing on the responder' is
addressed. There is an add
On Tue, 31 Oct 2017, mohamed.boucad...@orange.com wrote:
As per a suggestion from Tero, I’m sending this message to the list to ask for
more feedback on this short draft:
https://tools.ietf.org/html/draft-boucadair-ipsecme-ipv6-ipv4-codes-00
FWIW, the draft includes an “update” header becau
On Thu, 2 Nov 2017, Valery Smyslov wrote:
RFC7427 allows peers to indicate hash algorithms they support, thus
eliminating ambiguity in selecting a hash function for digital signature
authentication. However, recent advances in cryptography lead to a situation
when some signature algorithms hav
Valery Smyslov wrote:
Thanks for the review!
I found the document almost ready. A few editorial issues should be resolved.
1. Throughout the document attribute INTERNAL_DNSSEC_TA is often called
INTERNAL_DNS_TA.
Please, choose a single name :-)
Fixed. Should have been INTERNAL_DNSSEC_TA
Some systems support security labels (aka security context) as one of the
selectors of the SPD. This label needs to be part of the IKE negotiation
for the IPsec SA. non-standard implementations exist for IKEv1 (formerly
abusing IPSEC Security Association Attribute 10, now using private space
IPSE
Some people were interested in interop for the ppk draft.
We have implemented draft-fluhrer-qr-ikev2, and are going to
implement draft-ietf-ipsecme-qr-ikev2 in the near future.
To test, feel free to use the below server and let us know if you
had positive or negative results:
server: vpn-ppk.n
On Wed, 15 Nov 2017, Valery Smyslov wrote:
I’m a bit nervous since we are trying to find a quick solution
to an apparently not-so-easy problem in a rush time of WGLC.
I think we need more time for that, so we either should
drop the IIV for IKE and proceed with the current document
for ESP only
Hi,
We are looking at Opportunistic IPsec and supporting key rollover
support. In IKEv1, the initiator used the responder's key first,
and the responder could figure out which of its multiple keys the
initiator used. But in IKEv2, the responder uses one of their keys
and it does not really know
On Thu, 30 Nov 2017, Valery Smyslov wrote:
Doesn't ID_KEY_ID unambiguously determine the FQDN?
Yes, but indirectly and incoveniently.
Moreover, while ID_KEY_ID is often an opaque data, an FQDN
reveals perceived responder identity to an active attacker,
so there are some privacy concerns...
On Thu, 30 Nov 2017, David Schinazi wrote:
Regarding the original email, I'm not a fan of (1) as then implementations
have to handle receiving two different FQDN IDr's for example.
Having something like (2) where the new notify can only appear once
and it explicitly is there to select the key so
Since we interoperated with Tommy, I think we are getting in pretty
good shape with the document. If you want to test the PPK interop,
you can use the following test server:
server: vpn-ppk.nohats.ca
server id: vpn-ppk.nohats.ca (ID_FQDN)
group id (client id): GroupPPK1
PSK: "SecretPSK"
PPKID: "
On Fri, 1 Dec 2017, Tero Kivinen wrote:
1) Allow sending two IDr payloads in IKE_AUTH request
This will most likely break lots of implementations, and as this
happens before peer is authenticated, some of the will silently just
drop packets with generate INVALID_SYNTAX, i.e., which do not matc
On Mon, 27 Nov 2017, internet-dra...@ietf.org wrote:
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-00.txt
This draft was also submitted without marking it as replacing
draft-mglt-ipsecme-implicit-iv. This means there is no diff
available to read the changes :(
Can you fix that?
On Sun, 10 Dec 2017, Tero Kivinen wrote:
Yes, and I fixed it on 2017-11-27 as can be seen from
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/history/
and at least I can see the diffs on that page too...
Ah yes, now I could see the diff too. Thanks.
I'm fine with the docume
See:
https://tools.ietf.org/html/rfc7321
https://tools.ietf.org/html/rfc8221
8221 states properly:
Obsoletes: 7321
but 7321 is missing:
Obsoleted by: 8221
Can someone fix that?
Paul
___
IPsec mailing list
IPsec@ietf.org
https:/
On Tue, 19 Dec 2017, Tero Kivinen wrote:
8221 states properly:
Obsoletes: 7321
This is in the RFC text itself and this is the proper place to
indicate that this obsoleted something.
but 7321 is missing:
Obsoleted by: 8221
The actual RFC7321 cannot include text that it w
We have done a successful interop with Valerie for
draft-ietf-ipsecme-qr-ikev2-01
If anyone else wants to try:
Using the following private use numbers:
v2N_USE_PPK = 40960,/* draft-ietf-ipsecme-qr-ikev2-01 */
v2N_PPK_IDENTITY = 40961, /* draft-ietf-ipsecme-qr-i
On Mon, 22 Jan 2018, Paul Hoffman wrote:
Greetings. This document is still listed as in WG Last Call, although I haven't
seen anything in the archive about that Last Call closing.
Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times
already, and requested an early code point for I
ns
for the process in the case of Expert Review. Who to contact where?
Paul
Date: Mon, 22 Jan 2018 10:35:13
From: Tero Kivinen
Cc: "ipsec@ietf.org" , Paul Hoffman
To: Paul Wouters
Subject: Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns
Paul Wouters writes:
On Mo
On Sun, 21 Jan 2018, Paul Hoffman wrote:
So how about:
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA
may be
passed to another (DNS) program for processing. The content MUST be
verified to not contain any malicious characters, before it is
passed to
On Mon, 22 Jan 2018, internet-dra...@ietf.org wrote:
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-04
This version addresses the two points raised by Paul Hoff
On Tue, 23 Jan 2018, Linda Dunbar wrote:
Hi Linda,
Introduction:
Is "Split DNS" less about "configuration for the secure tunnels", but more
about having two zones, one to be used by the
internal network, the other used by the external network?
Basically Split DNS directs internal hosts to an
oduction of the document.
Thanks,
Paul
Linda
-Original Message-
From: Paul Wouters [mailto:p...@nohats.ca]
Sent: Tuesday, January 23, 2018 4:17 PM
To: Linda Dunbar
Cc: ipsec@ietf.org WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt
On Tue, 23 Jan 2018, Linda
On Tue, 6 Feb 2018, Tero Kivinen wrote:
While approving the IANA allocations I re-read the document again, and
I have some more comments that might make the document more
understandable.
Thanks!
In section 4.1 there is example of example.com, but it would be better
to put quotes around it it
On Tue, 6 Feb 2018, Tero Kivinen wrote:
It was actually a mistake (partially induced by my memory of rfc-8078
work and its errata). Those fields are all fixed length. Only the digest
itself is variable length, and as per 8078 errata, the shortest
representation would be "00", so two octets.
T
On Tue, 6 Feb 2018, Tero Kivinen wrote:
Some systems support security labels (aka security context) as one of the
selectors of the SPD. This label needs to be part of the IKE negotiation
for the IPsec SA. non-standard implementations exist for IKEv1 (formerly
abusing IPSEC Security Association A
]
16437 NO_PPK_AUTH [draft-ietf-ipsecme-qr-ikev2]
If you want to test certificate (RSA) based authentication using PPK,
let me know and I can give you a PKCS#12 to do PPK with RSA.
Paul
-- Forwarded message --
Date: Thu, 11 Jan 2018 00:58:45
From: Paul Wouters
Cc: 'Vu
On Wed, 7 Feb 2018, Tero Kivinen wrote:
It depends. If we do not take the item as official working group
chartered item, there are still few different options. You can either
get it processed as AD sponsored draft, or you can go individual
submission track.
It is a little strange we don't have
On Tue, 6 Feb 2018, Tero Kivinen wrote:
but this is not possible with current definition of the section 4.2,
where the DNSKEY Key Tag etc fields are mandatory. Thats why my
proposal was to make whole DNSSEC Trust Anchor Data optional.
Fixed in -06
I've submitted -05. My only question now is
On Mon, 12 Feb 2018, Valery Smyslov wrote:
This is one particular implementation peculiarity, there
will be others that behaves oddly. The point is, if we introduce a new
Transform Type, it is very likely that backward compatibility can no
longer be achieved.
Again, it depends. If the majority
On Fri, 16 Feb 2018, Tero Kivinen wrote:
The proposed charter text for this item is:
--
Some systems support security labels (aka security context) as one of
the selectors of the SPD. This label needs to be part of the IKE
nego
On Fri, 16 Feb 2018, Tero Kivinen wrote:
The proposed charter text is:
--
RFC7296 defines a generic notification code that is related to a
failure to handle an internal address failure. That code does not
explicitly allow an in
On Fri, 16 Feb 2018, Tero Kivinen wrote:
The proposed charter text is
--
MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from
one IP address to another. However, in MOBIKE it is the initiator of
the IKE SA (i.e
On Fri, 16 Feb 2018, Tero Kivinen wrote:
The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate f
On Fri, 16 Feb 2018, Tero Kivinen wrote:
IKEv2 is currently vulnerable to the two following privacy concerns:
1) It's not possible to run a server that obfuscates IKEv2/IPsec using
TLS.
2) The privacy of the initiator's identity in the presence of a man in
the middle attacker is not prot
On Wed, 21 Feb 2018, Tero Kivinen wrote:
In real life there is a NAT in most cases.
Use IPv6 :-)
Then there will not be problems with NATs...
Sadly, IPv6 NAT is happening and there is a request to add ESPinUDP
support for IPv6 in the Linux kernel :(
I think the topic is interesting and we
On Wed, 28 Feb 2018, Tommy Pauly wrote:
I’ve updated the draft with your comments as version -07:
https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt
Thanks for doing this. I would make one change (but it can be done after
IETF-LC)
[...] the content SHOULD be considered untr
t;any and all appropriate IPR disclosures
> required for full conformance with the provisions of BCP 78 and BCP 79 have
> already been filed."
>
> I will send it forward once I hear from each of you.
>
> Thanks,
> Dave
>
>> -Original Message-
>> From
Sahana and I wrote the initial draft for Labeled IPsec. I'm not sure
why it didn't auto-email the list, so links follow below. Please
discuss :)
Paul
A new version of I-D, draft-sprasad-ipsecme-labeled-ipsec-00.txt
has been successfully submitted by Sahana Prasad and posted to the
IETF reposit
On Tue, 6 Mar 2018, Hu, Jun (Nokia - US/Mountain View) wrote:
Some initial questions/comments:
1. security label is defined as opaque data in the draft, but then how would
narrowing work in an inter-op way with opaque data? Or should we define the
format for some common use cases (like securit
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
___
On Wed, 11 Apr 2018, Ron Bonica wrote:
- If we do nothing, tunnel performance is acceptable but suboptimal. We can
prevent blackholing by statically configuring the tunnel MTU to a sufficiently
low value. However, we cannot take advantage of tunnels with larger PMTUs.
- If we use IKE to exch
On Fri, 13 Apr 2018, Tero Kivinen wrote:
Paul Wouters writes:
Using IKE also has a disandvantage for for those implementations that
only support a window size of one. If those IKE messages are lost -
which is highly likely because we are trying out larger window sizes
until we find something
So during the last meeting when we discussed Labeled IPsec, a few
interesting items came up:
1) Is this actually a traffic selector ? Or is it a notify?
2) Is there a use case for "narrowing" on a security label ?
3) Can or should there be different labels in different directions ?
4) Can or sho
On Tue, 1 May 2018, Nico Williams wrote:
The following apply only to transport mode. However, a lot of this
generalizes to gateway uses as well.
- IPsec "state" should be more tightly bound to ULP state (PCBs)
For the implementation I'm working with (Linux with SElinux) we already
have the s
On Fri, 4 May 2018, Tero Kivinen wrote:
Traffic selectors in IKEv2 do have very strict processing rules, and
for most of the cases I do not think security labels will follow those
rules, or trying to force the security labels to follow those rules
will just cause confusion.
This includes ORing
On Thu, 3 May 2018, Nico Williams wrote:
I think this is true. Especially now it seems there is no narrowing to
be done from one security label to another one.
It depends on the label system.
For something like MLS you can narrow a label since labels actually
represent label sets or ranges, t
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 sa
On Tue, 19 Jun 2018, Eric Rescorla wrote:
Yes. You are the Enterprise customer. It's a feature.
Not all enterprises who use VPNs want to run a MITM proxy.
So only specify INTERNAL_DNS_DOMAIN with "internal.example.com"
and all TA's outside that domain would not be accepted by the client
On Tue, 19 Jun 2018, Nico Williams wrote:
The I-D should say that clients MUST allow local configuration of what
domains to accept trust anchors for, and SHOULD allow local policy to
list . as a domain for which to accept trust anchors.
It already says so:
If a client is configured by loca
On Tue, 19 Jun 2018, Nico Williams wrote:
The I-D should say that clients MUST allow local configuration of what
domains to accept trust anchors for, and SHOULD allow local policy to
list . as a domain for which to accept trust anchors.
Just one note. This draft is mean ONLY for use with split
On Tue, 19 Jun 2018, Eric Rescorla wrote:
1. In the current design, many clients (those whose enterprises have any
significant number of domains) are just going to have to accept
whatever domains the VPN server claims should be treated as internal, and to
accept the trust anchors the VPN serve
On Tue, 19 Jun 2018, Eric Rescorla wrote:
The ID can say that, but as a practical matter, any enterprise that has
a reasonable number of internal domains is just going to tell people
to configure their client to accept any domain name.
Which is the equivalent of an enterprise that requires you
> On Jun 19, 2018, at 18:46, Nico Williams wrote:
>
>
> Because my VPN clients don't connect promiscuously. I can't say no
> promiscuous VPN clients exist, but I imagine that none do. And any
> promiscuous VPN clients get what they deserve.
Opportunistic IPsec exists and are “promiscuously”.
On Tue, 19 Jun 2018, Eric Rescorla wrote:
I'm asking if a common scenario will be that users of enterprise
VPNs who implement this feature will end up in a situation where the
VPN can impose TAs for any domain.
I explained before that I think "for any domain" can be strictly limited
on the cli
On Tue, 19 Jun 2018, Eric Rescorla wrote:
Yes, that's technically true, but the question is whether it's in fact
practical for people to do that.
I already responded before that yes I think it is practical.
I'm sorry to repeat myself, but once
again the document clearly states that this can
On Wed, 20 Jun 2018, Eric Rescorla wrote:
I thought I had made clear what was bothering me, so I suppose we must be
talking past each other. I read this text as saying that there are
important cases where in fact the client will not have any reasonable way of
knowing which domains to accept f
On Wed, 20 Jun 2018, Benjamin Kaduk wrote:
This seems like the main fear, yes, but perhaps not exclusively so.
It's kind of how users "always" click through certificate warnings in
browsers, or "alway" grant a mobile app all the requested permissions.
If, to expand unreasonably upon a previous e
Hi,
According to https://msdn.microsoft.com/en-us/library/cc233476.aspx
Microsoft Windows 10 v1803 (Windows April 2018 Update) has support for
IKEv2 fragmentation. However, I am getting reports of people who are
fully up to date and still their IKE daemon doesn't seem to send the
IKEv2 fragment
I was pointed to two drafts about using IPsec for transporting virtual
machine network traffic. Specifically, its use of AH is what I'm a
little concerned about, as I was hoping the IPsecME WG could start work
soon at obsoleting AH and recommend ESP-null for the remaining use cases.
IPsec over
On Thu, 19 Jul 2018, Tero Kivinen wrote:
Thanks for Brian Weis taking minutes from the IPsecME WG meeting. I
did some editing and posted them on the datatracker:
https://datatracker.ietf.org/meeting/102/materials/minutes-102-ipsecme-00
ossible mis-use by DNS server -> possible mis-use by VPN s
We had to support the following deployment.
A large group of nodes is deployed with mutual authnull. This
offers passive attack protection on the network. At a later
stage, nodes are given their certificate for authentication.
The goal was to go from mutual authnull to mutual RSA. If either
no
On Thu, 19 Jul 2018, Scott Fluhrer (sfluhrer) wrote:
If you ask my opinion, I think it's cleaner if we use fresh nonces; however I
do not believe that there is any security difference.
Yes, let us never ever re-use nonces just to make it super clear what a
nonce is, even if it would be harmle
On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote:
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11
This is probably wrong:
Any INTERNAL_DNSSEC_TA a
On Thu, 19 Jul 2018, Tero Kivinen wrote:
Paul Wouters writes:
So we have the following possibilities:
1) authby=authnull -> authby=authnull
2) authby=authnull,cert -> authby=authnull
3) authby=authnull,cert -> authby=authnull,cert (must yield real
authentication)
4) authby
On Thu, 19 Jul 2018, Tommy Pauly wrote:
Because you can have more then one INTERNAL_DNSSEC_TA for one domain.
Instead, it should read:
Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to
Some note would be good because apparently strongswan insists of the KEY_LENGTH
attribute they shouldn’t be there?
Sent from my phone
> On Jul 26, 2018, at 12:06, Yoav Nir wrote:
>
> This errata proposes to add the following sentence to section 4 of RFC 7634:
>
> As with other transforms that
Just ran into this, probably this group should have a look at it (I haven’t yet
myself)
https://tools.ietf.org/html/draft-annu-t2trg-ike-for-wsn-security-00
ike for wsn security
INTERNET-DRAFTAnnu
Intended Status: Standards Track
None of this seems related to ipsec and things should be discussed elsewhere..
If there is a component related to IKE or IPsec, please clarify as your list
archive or the draft you link to provide information showing this to be on
topic here.
Paul
Sent from my phone
> On Aug 10, 2018, at 10:
On Thu, 26 Jul 2018, Daniel Van Geest wrote:
I do have one issue I’ve been pondering, though; we do an IKE_AUX exchange, and
then follow it up with an IKE_AUTH
I agree, the name is not the best for verbal language.
I have the same issue when discussing the draft. Off the top of my head,
I
FYI,
https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
Sent from my phone
Begin forwarded message:
>
> https://www.bleepingcomputer.com/news/security/cisco-patches-its-operating-systems-against-new-ike-crypto-attack/
>
> Cisco Patches Its Operating Systems Agains
On Tue, 14 Aug 2018, Valery Smyslov wrote:
after reading the paper I still don’t understand why authors mentioned IKEv2
there.
Their example attack in Section 4.4 on (allegedly) IKEv2 in fact uses secondary
responder
supporting IKEv1 Public Key Encryption mode, without which the attack is
i
On Tue, 14 Aug 2018, Scott Fluhrer (sfluhrer) wrote:
They also do some number games about how many packets you need to
send and how fast, and I found their description confusing. I think they
change SPI (cookies) and so these would be "new" exchanges so this has to
be the DH component, but even
On Tue, 14 Aug 2018, Scott Fluhrer (sfluhrer) wrote:
This is not a MITM attack, this is an impersonation attack.
If it is not a MITM, then the original connection will establish.
What original connection? Mallet (the attacker) claims to be Alice (a valid
node), and initiates to Bob. When
On Tue, 14 Aug 2018, Tero Kivinen wrote:
In IKEv2 you can do active attack to do offline dictionary attack.
When Alice is trying to connect Bob, the Mallery will take those
packets and respond to them, without forwarding anything to Bob. When
Alice will send her IKE_AUTH payload, you can decrypt
On Sun, 19 Aug 2018, Stefan Santesson wrote:
Reviewer: Stefan Santesson
Review result: Has Nits
Thanks for your review.
In agreement with nit comments in the Gen-Art review.
1) Section 2. Background seems to be a duplication with the introduction
section and could probably be merged with th
On Wed, 15 Aug 2018, Bruckert, Leonie wrote:
Obviously, in order to achieve PFS in the sense of PQ security, we need to
perform at least one PQ key exchange for Child SAs. At this point
of the protocol, the peers already know if both of them support PQ algorithms,
so backwards compatibility s
On Fri, 31 Aug 2018, Tero Kivinen wrote:
There is no requirement for SPI to be random and originally it was
written that way so implementations can use whatever method to
allocate SPIs they like.
However, the randomized SPIs does give us some security, as we saw in
the SLOTH attack, that was o
On Fri, 7 Sep 2018, Valery Smyslov wrote:
I've posted a draft with clarifications and implementation guidelines
for RFC8229. These clarifications and recommendations are based
on experience of implementing TCP encapsulation and testing it in
various IKEv2 scenarios.
Feedback of any sort is high
On Thu, 18 Oct 2018, Tobias Guggemos wrote:
With the new mode, the sender can decide to send certain packets “uncompressed”
if the receiver may not be able to decompress properly. The sender notifies the
receiver by using a different SA and thus a different SPI.
We believe this is more clean t
> On Nov 1, 2018, at 06:03, Tero Kivinen wrote:
>
> Scott Fluhrer (sfluhrer) writes:
>> My issue with this general idea is backwards compatibility; if we
>> issue a transform of type 5 to an old IKEv2 system, it may reject
>> the entire exchange with an "unrecognized transform type" error (and
Some other bike shed colours
IKE_INIT_C - Init Continued
IKE_INIT2
IKE_BE - Blob Exchange, Bulk Exchange
IKE_LARGE
IKE_BULK
IKE_BIG_KE
IKE_LARGE_KE
I think IKE_SA_INIT is misnamed and should have been IKE_INIT,
or IKE_AUTH should have been IKE_SA_AUTH :)
I don't like IKE_CONT[INUE] because it
On Fri, 16 Nov 2018, Waltermire, David A. (Fed) wrote:
One comment on your COMMENT wearing chair and shepherd hats:
We have to use DNS presentation format for the DS records and not wire
format?
The group was "split" on this question. We did a hum, with most responding in
the room that they
On Wed, 14 Nov 2018, Yoav Nir wrote:
As discussed in the room, we need some reviewers for the
sdn-ipsec-flow-protection draft ([1])
Thanks for these comments. Please see our response below.
While any comments on any part of the document are welcome, I would like people
to concentrate on the
On 2018-11-18 12:40 a.m., Alexey Melnikov wrote:
--
DISCUSS:
--
This is a well written document, so thank you for that.
I've noticed that Benjamin already found
On 2018-11-18 6:14 p.m., Tero Kivinen wrote:
Actually the text in section 2.2 is confusing. It is claiming that
This attribute lists the corresponding internal DNSSEC
trust anchor in the DNS presentation format of a DS record as
specified in [RFC4034].
The format we use for DS record
On Mon, 19 Nov 2018, Linda Dunbar wrote:
When you said “IPs are sourced loopbacks that are part of a prefix exported to
the the isp(s) in each site”,
do you mean that the private Loopback addresses of CPE1 & CPE2 are routable in
all four ISPs’ that
connected to A1, A2, B1, B2?
And to clarif
On Tue, 20 Nov 2018, Michael Richardson wrote:
Tero Kivinen wrote:
> Presentation format includes things like comments, newlines,
> whitespace etc.
> That is the reason I do not like to have presentation format inside
> the binary wire formats like IKE. We do not need to do string
On Tue, 20 Nov 2018, Tero Kivinen wrote:
Yes, as I have seen so many times that people pass strings for
configuration directly from the remote end to the configuration file,
either because of it is easy, or by accident (shellshock, all kind of
CGI issues etc).
That's why we have the Security C
On Mon, 19 Nov 2018, Rafa Marin Lopez wrote:
Based on the introduction and abstract of the draft, this document does two
things:
1) Specify a yang model for use with SDWAN + IKE + IPsec
2) Define the desired modes and algorithms to use with 1)
It does not try to map the entire IKE/IPsec IANA
> On Nov 21, 2018, at 00:54, Yoav Nir wrote:
>
> Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linux
> can work, which is why I agree with your conclusion, except for the tweak
> that MUST- is also OK.
Okay, if one of the expected deployments is 10 year old ikev2 code,
1 - 100 of 915 matches
Mail list logo
