Hi,
> Has anybody implemented this yet?
Yes.
Good to know. Do you know if there has been any interoperability tests
with it?
We are interoperable with ourselves (not a surprise) and with strongSwan
(no RSASSA-PSS was tested yet though).
I think it is a deficiency of RFC7427 that it only
If RSASSA-PSSv2 is done because RSASSA-PSS is found broken, then we
just mark RSASSA-PSS as MUST NOT, and move to the new version.
And this will cause interoperability problems since there is no way for the peers
to indicate each other that they support particular signature encoding.
"MUST NOT
Hi Tommy,
sorry for late reply. I'm mostly OK with the last version of the draft.
Few comments. It is a bit unclear how Stream Prefix is intended
to be used with TLS. Is it insterted at the beginning of the TLS data stream?
Then, I think some text should be added describing a situation
when the
the prefix completely? In this case how many bytes
should it skip from the beginning of the stream - exactly 5?
Regards,
Valery.
- Original Message -
From: "Tommy Pauly"
To: "Valery Smyslov" ; "Yoav Nir"
Cc: "Paul Wouters" ; "Daniel Migault"
Hi Paul,
thank you for clarifications. One more point. The draft is silent about
what the responder is supposed to do with the stream prefix.
Should it check it? In this case what should it do if the prefix is
different from "IKEv2"? Discard the TCP session? Or should
it ignore the prefix comple
Hi,
in Buenos-Aires it was expressed a proposal to split
the DDoS protection draft into two. One of them would
describe possible kinds of (D)DoS attacks and would
suggest some counter measures to thwart them without
introducing anything new into the IKEv2 protocol.
The other document (with Exp
Hi Paul,
On the other hand, if we go this way and give the puzzles stuff an
Experimantal status, then probably very few vendors (if any) will implement
it and the real problem of defending against
(D)DoS attacks will remain unaddressed.
I don't think the puzzles implementation adoption will
The concern is not about stand-alone puzzles document. It is about an
Experimental status
of that document versus Standards Track in the current draft. Vendors tend to
ignore Experimental RFCs.
The conventional wisdom is that vendors tend to ignore whatever status the IETF assigns to documents
Hi Paul,
thank you for the very thorough review (and especially - for the nits).
This is a partial review of draft-ietf-ipsecme-ddos-protection-06
up to Section 6. I hope to complete the rest in the next few days.
I think this document needs another revision before continuing.
(and I would pre
Hi Paul,
An obvious defense, which is described in Section 4.2, is limiting
the number of half-open SAs opened by a single peer. However, since
all that is required is a single packet, an attacker can use multiple
spoofed source IP addresses.
I am not sure why this is mentione
This is the official call for adoption of https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an
IPSecME working group (WG) document.
By adopting this draft the WG is agreeing to take this on as an official WG item to continue work on the draft. Please
reply with any comments su
[ cut everything we agreed ]
> > Depending on the Responder implementation, this can be repeated
> > with
> > the same half-open SA.
> >
> > I don't think this "depends on the implemention". Since any on-path
> > attacker can spoof rubbish, a Responder MUST ignore the faile
Hi Daniel,
a couple of comments. RFC 3686 Section 6 provides design rationale for making
an IV explicit.
I think it will be good if your draft also gives some design rationale why you
came
to the opposite conclusion (just to give readers an insight why in IoT world
the weight of different facto
al Message -
From: "Waltermire, David A. (Fed)"
To: "Valery Smyslov" ;
Cc: ; "Yoav Nir"
Sent: Wednesday, June 22, 2016 8:21 PM
Subject: RE: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06
Paul and Valery,
We are extremely close on wrapping up this dra
HI Paul,
I'd rather change it a bit:
When the Responder is under attack, it SHOULD prefer previously
authenticated peers who present a Session Resumption ticket [RFC5723].
However, the Responder SHOULD NOT swich to resumed clients
completely (and thus refuse every IKE_SA_INIT reques
Hi,
I support adopting this document. I think we need to have a PQ-secure solution
in IPsec.
I'd like to see it generic enough and not limiting to QKD technology only. I'd
also like
to have IKE SA to be protected, as well as Child SAs, so that this solution can
be used
in cases when sensitive
Hi Dave,
thank you for your review.
I just completed a review of the DDoS draft. I fixed a number of grammar and wording issues. I would like to issue a
pull request, but I don't have access to the site yet. I hope to get that resolved ASAP and then submit the pull
request.
While I was revie
Hi Paul,
thank you for part two of your review.
This is part two of my review. I do think the document needs some work
moving text to better locations and I have some questions I would like
to see resolved. I wrote down some nits but stopped doing that in the
end because I think chunks of text
Hi Tero,
To be clear - I'm not against updating RFC 7296, I just think it is
not needed.
I think the rules are
All documents which do change IKEv2 core behavior are marked as
updates 4306/5996/7296. Currently those are:
...
If there is negotiation of this feature before the IKEv2 behavior
c
uted
Denial of Service Attacks
Authors : Yoav Nir
Valery Smyslov
Filename: draft-ietf-ipsecme-ddos-protection-07.txt
Pages : 29
Date: 2016-07-01
Abstract:
This document recommends implementation and configuration best
practices
Hi Paul,
Isn't this kinda off-topic for the thread? I though we were first considering
"create an IKEv2 extension that mixes in the PSK" as the simplest way to get
around the "go back to IKEv1" guidance.
So that was not entire clear to me from the title, but it seems you are
right.
Perhaps w
The draft provides postquantum protection to any SA, regardless
of the authentication methods used. In other words, PPKs (as specified in the
draft)
don't replace preshred keys authentication in IKEv2, they augment
any authentication method to provide postquantum security.
The original title
Hi Tero,
I think it is a bit early to discuss particular approaches,
before the WG makes a decision to adopt the document.
However, just for the record (see below).
Earlier I have proposed very simple method where the IKE_SA_INIT
contains just some kind of notification messages identifying the
Hi,
just to reiterate my position in light of this questionnaire:
This has been a good discussion so far. There is work to be done to address the
issues raised.
Getting back to the call for adoption, I'd like to see feedback on the following questions to better understand where
consensus is
Hi,
Not necessary. In particular, the current draft allows to detect
OOB key mismatch and to act gracefully in this situation.
And I don't think it is far too complicated.
Current draft does, but there has been other proposals which did not.
The current draft is also very costly and allows v
Hi,
- Add Quantum Resistance for IKEv2 as new work item with milestone as
Feb 2017 for IETF LC.
This milestone looks a bit optimistic for me.
Otherwise the updated chapter looks good.
Regards,
Valery.
___
IPsec mailing list
IPsec@ietf.org
https:
Hi,
On the other hand, we need to give people some guidance somehow...
Do we? Who is "we"? Why is "our" guidance any better than what they get
from their own experts, particularly if "our" guidance gets ossified in
an IANA registry or RFCs that are updated slowly?
Instead of listing QR-sec
Hi Scott,
thank you for the list of requirements. My answers are inline.
In Berlin, we decided to take up Quantum Resistance as a work item, and that
we should start talking about requirements. I'm starting this thread in a hope
of kicking off the discussion.
First of all, a solution
Hi Yaron,
Can we make all the compression algorithms SHOULD NOT instead of MAY?
TLS got rid of compression altogether, there are numerous attacks on
compressed traffic, and even the document states that these algorithms
are not widely implemented.
What attacks do you mean? Those that I'm awa
Yaron,
I don't think these attacks are relevant to ESP compression.
As far as I understand, they rely on statistical analysis
of the frame lengthes when phonems are encoded with a
lossy compression algorithm. I don't see how it affects
losless compression used in ESP.
Regards,
Valery.
Va
Hi Valery,
Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with
lossless algorithms. And as far as I know, they are applicable to any
situation where here is an attacker that can force traffic on the wire,
mixed with other, non-attacker controlled traffic. So IMO they are not
And ESP compression could help applying TFC padding without consuming
considerable anount of additional bandwidth.
You mean TFC pad to something that's not the MTU ?
Probably, but not necessary.
Not sure I see how compression + TFC makes smaller packets, unless your
TFC padding is very small
Hi Kathleen,
thank you for the review. I'll try to answer.
Hello,
Thank you for you work on draft-ietf-ipsecme-ddos-protection. This is
a good read that lays out the problem well and describes the solution
well. Thanks for that!
I have some nits and questions before we put this into IETF la
IETF.
Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed
Denial of Service Attacks
Authors : Yoav Nir
Valery Smyslov
Filename: draft-ietf-ipsecme-ddos-protection-09.txt
Pages : 29
Hi,
here is my review of draft-ietf-ipsecme-rfc4307bis-13.
I didn't participate in the recent discussions,
so I'm acting here more or less like "fresh" reader.
Overall, I think that the document is in a good shape, however some
additional polishing is required to improve its clarity and elimina
Hi,
I support adoption of this document.
Regards,
Valery.
This is a quick reminder that the call for WG adoption on draft-mglt-ipsecme-rfc7321bis ends on Wednesday, September
14th, 2016 at UTC 23:59.
I have not seen any support or concerns posted in response to my initial email. While this
Hi Paul,
We have kept key lengths out of the tables on purpose. It matches the
tables at IANA that also do not list separate items for different key
lengths. Would "This requirement" instead of "This requirement level"
make that more clear?
If you don't want to add key length column to the tab
Hi Tero,
> | RSASSA-PSS with Empty Parameters | MUST NOT | |
> | RSASSA-PSS with Default Parameters | MUST NOT | |
>
> Well, I'm a confused with these requirements. As far as I
> understand the RSASSA-PSS parameters default to using a SHA1 for
> both hashAlgorithm
Hi,
we recently ran into one interoperability problem that is concerned
with RFC 7427.
We start testing RSASSA-PSS with another vendor product and found,
that while it supports Digital Signature authentication method, it seems
to not support RSASSA-PSS signatures in IKE. As a result, the SA
is
Hi Mirja, Yoav,
I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).
> --
> COMMENT:
> ---
Hi,
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-14
These are the changes based on Valery's feedback.
my concerns are resolved.
Thank you,
Valery.
Paul
ps. I hope Valery will assist me when testsuites or testlabs ask
ype of the following payload, not the type of payload
the diagram depicts.
There is also an IANA Considerations Section which also specifies the
payload type for the Puzzle Solution payload.
Thank you,
Valery Smyslov.
Alexey Melnikov has entered the following ballot position for
draft-ietf-ip
;
Is this supposed to say 2014? Struck me as a little weird.
The -00 version of the document was written in 2014,
so the estimates came from Yoav's experiments,
that he conducted at that time, I think.
Regards,
Valery Smyslov.
___
IPsec mai
recommends
changing secret frequently if under attack (RFC7296, Section 2.6):
The responder should change the value of frequently, especially
if under attack.
I think we can add some words to the draft that will recommend
to generate cookie in such a manner, that the cookie is not repeat
Hi Tero,
[This is bit old email, but I have not seen any replies to this, and I
am sending this as implementor not as chair.]
Valery Smyslov writes:
The problem is that RFC7427 doesn't provide any means to find out
what kind of signatures peer supports. If you have RSA certificate,
you
Hi Yoav,
No this was different issue. I remember that discussion very well (since
I initiated it) and I wouldn't start it over again.
The issue we came across is not about different algorithms
(say indicating whether we need to use RSA or ECDSA if we have
both certificates). The algorithm is ess
Hi Paul,
I don't think negotiation is needed. It's enough if each side announces its
capabilities,
the same way it is done in RFC7427 with hash functions. And the easiest way
to do
it is to add pseudo-hash value "RSASSA-PSS supported" into the hash
algorithms registry.
In this case each side w
Sure. I can prepare the slides (if the WG chairs don't mind).
Regards,
Valery.
Perhaps we (as in the working group) should schedule some time (15-20 minutes?)
to discuss the options in Seoul.
Understanding both RFC 7427 and PSS signatures when they are in certificates,
but not PSS signatures
Do you really think we will see this more in ECC? How will that happen
more in the ECC?
If I have Ed25519 key, why would someone go against the "SHOULD NOT"
in draft-nir-ipsecme-eddsa draft and use something else than Ed25519,
i.e., why would someone use Ed25519ph, or why would someone use ECDSA
The reasons can be various. For example, after wide adoption
of EdDSA some vulnerability is found in the scheme and some
modifications are introduced to eliminate it (analogously to
If there would be vulnerability in the signature scheme, I think we
would say you MUST NOT use the old format
s are very welcome.
Regards,
Valery.
- Original Message -
From:
To: "Valery Smyslov"
Sent: Friday, October 07, 2016 6:18 PM
Subject: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt
A new version of I-D, draft-smyslov-ipsecme-ikev2-compact-
s are very welcome.
Regards,
Valery.
A new version of I-D, draft-smyslov-ipsecme-ikev2-compact-00.txt
has been successfully submitted by Valery Smyslov and posted to the
IETF repository.
Name: draft-smyslov-ipsecme-ikev2-compact
Revision: 00
Title: Compact Format of IKEv2 Payloads
Document
.
Regards,
Valery Smyslov.
- Original Message -
From: Hu, Jun (Nokia - US)
To: IPsecME WG
Sent: Friday, October 07, 2016 8:33 PM
Subject: [IPsec] vendor support of RFC7427
Hi,
I plan to support RFC7427 on my product, however as part of inter-op
planning, I'd like to
Hi Daniel,
I think you should add a text in the Security Considerations that these
transforms MUST NOT be used in situations where there is a chance that
Sequence Numbers repeat. The most prominent example where it can happen -
multicast ESP SA with multiple senders.
Regards,
Valery.
Hi,
Bas
.
On 25.09.2016 22:20, Valery Smyslov wrote:
Hi Mirja, Yoav,
I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).
---
>
> -Ursprüngliche Nachricht-
> Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Valery Smyslov
> Gesendet: Montag, 10. Oktober 2016 09:06
> An: Daniel Migault ; IPsecME WG
> Betreff: Re: [IPsec] FW: New Version Notification
> fordraft-mglt-ipsecme-implicit-
multicast scenarios.
>
> Thanks
> Tobias
>
> -Ursprüngliche Nachricht-
> Von: Valery Smyslov [mailto:sva...@gmail.com]
> Gesendet: Donnerstag, 20. Oktober 2016 10:16
> An: 'Tobias Guggemos' ; 'Daniel Migault'
> ; 'IPsecME WG'
> Betreff: RE: [IPse
Hi,
I have almost the same list of questions as Yoav’s list. But main question is -
how are you going to ensure that load balancer delivers ESP packets
to the same cluster node where IKE messages that create this ESP SA
were delivered? In other words, load balancer must deliver ESP packets
single point (SK_d’ derivation) where modifications to keys
derivation algorithm
take place, instead of two points. It will make implementations modification
easier, I think.
So, did you consider such variant? Are there any security disadvantages?
Regards,
Valery Smyslov.
From: Scott Fluhrer
Hi Jun,
for the second part: your IKE SA must be linked to all child SAs
it created (in other words, child SAs must remember which IKE SA
created them and visa versa, otherwise a lot of IKEv2 logic
doesn’t work). So there is no need to send packets over all
child SAs, it’s enough to send liveness
: 14 ноября 2016 г. 23:07
To: Valery Smyslov; IPsecme WG (ipsec@ietf.org)
Subject: RE: [IPsec] FW: Quantum Resistance Requirements
No, we didn’t consider modifying things there.
The main reason we wouldn’t have considered that is a possible complication to
crypto hardware; if we assume that we had
What’s wrong with that?
As far as I understand the draft, the mapping between IKE/IPsec and TCP is
loose,
so it seems that such a scenario is OK (Tommy corrects me if I’m wrong).
Do you have any problems with it?
From: Hu, Jun (Nokia - US)
Sent: 15 ноября 2016 г. 10:48
To: Valery Smyslov
.
Regards,
Valery Smyslov.
From: Yoav Nir
Sent: 18 ноября 2016 г. 11:31
To: Watson Ladd
Cc: ipsec@ietf.org WG
Subject: Re: [IPsec] Take a stand for key hygine
Hi, Watson
On 18 Nov 2016, at 9:18, Watson Ladd wrote:
> Dear all,
>
> In reviewing the proceedings now online I not
Hi Yoav,
or the servers must be provided with two certificates – one for TLS 1.2
and the other for TLS 1.3, that won’t make server owners happy.
I think it is a good idea to raise this issue in TLS WG.
Regards,
Valery.
From: Yoav Nir
Sent: 19 ноября 2016 г. 7:21
To: Tero Kivinen
Cc: ipsec@iet
Hi Watson,
the problem is not that the host cannot deduce from received AUTH payload
what kind of signature was used – the AUTH payload includes AlgorithmIdentifier,
so these signatures are treated differently. The problem is that host cannot
guess what kind of signatures the peer supports, that c
Hi,
o Valery Smyslov gave a suggestion that we instead stir in the PPK
into the initial SK_d; as all keying material is generated based on
that, this would also mean that IPsec SAs and any child IKE SAs are
also protected. This also means that an implementation would not need
to remember the
Hi,
I have one concern with the current draft: how to gracefully handle the
situation
when PPKs on initiator and responder don't match (due to configuration error
or PPK update). With the current draft this situation isn't handled at all:
after creating Child IKE SA both peers will end up with n
Hi Tommy,
I think the new text substantially simplifies implementations.
Thank you,
Valery.
> Hello all,
>
> I've updated the TCP Encapsulation draft with new recommendations around
> handling the mapping
> between IKE SAs and TCP Connections based on the conversation at the Seoul
> meeting.
Hi Tero,
> > CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But
> > CREATE_CHILD_SA doesn’t allow to exchange identities. So, if
> > pseudonyms were used in IKE_AUTH, how are you going to exchange real
> > identities?
>
> Real IDs are never exchanged over wire. The server sees pseudonym
Hi Tero,
as far as I understand, this proposal is not tied up with QR problem
and can be used independently. So I suggest not to mix it with
the proposed QR solution in one document.
Regards,
Valery.
> > Then what is the content of IDi and IDr in IKE_AUTH in this case?
>
> As I said the IDi wou
Hi again,
> I would propose that we add PPK to both SK_d and SK_pi and SK_pr.
>
> SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs.
> The SK_pi and SK_pr provides key verification, meaning that incorrect
> PPKs will result AUTHENTICATION_FAILURE notification, instead of just
>
Hi Scott,
> > Would it be reasonable to create some token/nonce from something before
> > the PPK is mixed in such that we could recognize the different AUTH
> > FAILUREs, or does that create too much of an oracle for testing PPKs?
>
> I believe that would be reasonable. We already exchange noti
Hi Michael,
> Scott: how do you think PPKs will get entered initially (i.e. until we have
> some quantum-resistant mechanism to distribute them)? Humans typing them
> in, QR codes scanned, USB keys sent via Fedex? If we are serious about
> this, then it matters.
>
> If Humans is the answer, t
Hi Tero,
> --
> >From section 3.2
>
>If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-
>zero lengths, the CFG_REPLY MUST NOT assign any domains in its
>INTERNAL_DNS_DOMAIN attributes that are not contained within the
>requested domains. The initiator SHOULD ign
Hi once more,
>The streams of data sent over any TCP connection used for this
>protocol MUST begin with the stream prefix value followed by a
>complete message, which is either an encapsulated IKE or ESP message.
> ...
>
> I think this should be rephrased in a way that when initiator
> > > This way if you have originally configured company1.com to the
> > > internal dns names, and then company decides to buy another company
> > > called company2.com, teh client can still request company1.com and
> > > server can return both company1.com and company2.com in its reply.
> > > Then
> > Isn't it easier to add a requirement that the received message must
> > not be a replay? For example:
> >
> > It should choose the TCP
> > connection on which it last received a valid and decryptable IKE or
> > ESP message that is not recognized as a
> > > Initiator then recreates tcp session with responder and sends some ESP
> > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
> > > TCP connection, creates completely new TCP session and replays the old
> > > ESP message with sequence number of 0x1000 (which was not seen by
Hi Tero,
> > If attacker intercepts TCP session carrying ESP packet with sequence
> > 0x1000 and manages to get the packet and drop the TCP session before
> > responder gets it, then it can create a new TCP session
> > sending this packet. The responder will switch to the attacker's
> > TCP sessio
HI Tero,
> Actually Valery did raise good point, that for IKE this might cause
> issues.
>
> Now when I am thinking about this, I think that for IKE packets the
> response to the IKE request should go to the same TCP session where
> the request came in. This would be aligned with the RFC7296 whic
Hi Tommy,
> >> Actually Valery did raise good point, that for IKE this might cause
> >> issues.
> >>
> >> Now when I am thinking about this, I think that for IKE packets the
> >> response to the IKE request should go to the same TCP session where
> >> the request came in. This would be aligned wit
Hi,
I support adoption this document. I think it presents a useful functionality.
Regards,
Valery.
> This is the call for adoption of
> https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/
as an
> IPSecME working group (WG) document.
>
> By adopting this draft, the WG is agreeing to
Hi,
here is my review of draft-ietf-ipsecme-tcp-encaps-05.
The draft is in a good shape, but a bit of final polishing is required.
1. The terms "tunnel", "tunneled" are used throughout the document
when referring to ESP SA. I think it is technically incorrect, since
ESP supports both tun
> Hi Valery,
>
> Thanks so much for your comments! I have posted a new version of the draft
> here:
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06
>
> Responses inline.
>
> Best,
> Tommy
>
> > On Feb 2, 2017, at 4:13 AM, Valery Smyslov wrot
n parallel, then
in some cases TCP will win even if UDP works, resulting in non-efficient
connection, even when UDP could be used.
-Ekr
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.i
Hi Yoav,
> I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section
> 12), so it is considered
> as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start
> trying TCP and UDP in para
I think it won't be wrong if the document is adopted.
I'm not a big fan of implicit IV, but I agree that it may be useful in some
cases.
However there are not always obvious pitfalls that may
make it insecure. I prefer to have these pitfalls been
documented and explained, that's why I support adop
Hi,
> So I have proposed earlier that we should mix the ppk to SK_d, SK_pi,
> and SK_pr, i.e., something like this:
>
>SKEYSEED = prf(Ni | Nr, g^ir)
>
>{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'}
> = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
>
>If no
Hi Scott,
> I started editting the draft to incorporate this change, and I ran into a
> conflict with another
part of the
> protocol: incremental rollout. I'd like some quick advice about how to deal
> with the conflict.
>
> Here's the feature it's in conflict with: in order to support 'brown-
Hi Tero,
> > I think that if SK_pi and SK_pr are modified, then some information
> > should be given to the user to help distinguish PPK errors from
> > signature errors. For example, the Initiator can include something like
> >
> > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0)
> >
> > into the IKE_AUT
Hi,
> > > The NULL authentication (RFC7619) is logically incompatible with this
> > > (it being opportunistic and this requiring configuration), so I think
> > > we can say this will not be used with it. Or we can just say that can
> > > be used, and SK_pi are used as specified here and in the RF
Hi Tero,
> I.e., when you configure node A for PPK use, you need to give node A
> all the PPKs for all peers it has. I.e., the configuration loaded on
> the node A needs to provide all PPKs it will need.
If node A is mostly an initiator (e.g. a remote access client),
then it knows beforehand to w
Hi Scott,
> The issue I was pondering was "what if the admin wants to update only part of
> their network (say,
as a
> test)?". As I understood your proposal, the PPK_SUPPORT notify was always on
> if any PPKs were
> configured; indeed, from a responder side, it has to be that (because the
> r
> > I'd rather add a type field to ppk_id. So the ppk_id is constructed
> > of 2 fields: type and value. Types could be:
> > 1. raw id
> > 2. OTF file offset
> > 3. PPK dependent id
> > ...
> >
> > For the 3rd option the ppk_id is constructed using the PPK
> > itself and a session parameters, e.g.
Hi Paul,
> >> For the 3rd option the ppk_id is constructed using the PPK
> >> itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr).
> >> This would allow the responder to check whether PPK is correct
> >> before verifying AUTH payload.
> >>
> >> In general, having a type value would si
Hi Scott,
> I've been pondering another question, and I think I'll bring it up before
> finalizing the next
version of the
> draft.
>
> After the WG meeting, we (Tero and myself) met in the hallway and had a
> little chat. One of the
things
> that I took away from it (and please correct me if
ut some interoperability problems:
> > https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html
> >
> > This issue is scheduled for discussion on ipsecme meeting in Seoul.
> >
> > Regards,
> > Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
now the session keys etc.
It is more fragile too. You must perform periodical rekey (update keys)
and this must be done synchronously. All the rekey problems that were
solved by IKE will arise again.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec
Hi Rafa,
Hi Tero, Valery:
Please see inline.
El 18 jul 2017, a las 17:06, Tero Kivinen escribió:
Valery Smyslov writes:
I'm very much concerned with the IKE-less option presented in the
draft.
First, the Network Controller becomes a very attractive target for
attacks in
use an old one despite the fact that it is expired?
Block all traffic? Something else?
How NAT traversal is to be done in IKE-less case? I understand, that
NATs are also controlled by SDN, but does SDN pre-install NAT mappings?
Regards,
Valery.
> Regards,
> Alejandro
>
> >
801 - 900 of 944 matches
Mail list logo
