Thanks for minutes takers for taking the minutes in the etherpad. I
cleaned them up bit, and posted them to the meetings materials page:
--
IETF 103 IPsecME WG meeting in Bangkok
Wednesday, November 7, 2018
13:50-15:20
Scott Fluhrer (sfluhrer) writes:
> > That implementation is broken, and needs to be fixed.
>
> I can easily see a manufacturer claiming "my implementation has been
> working without a problem for 13 years; why does it need to be
> fixed?"
And the answer will be: Because it is broken, and it is
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
> yes, there are real systems that behave this way).
That
We seem to have very short meeting, or at least we do not have that
much things we want to discuss in next meeting in Bangkok. I have only
received 2 agenda items, and one comment that we should discuss IPsec
Compression mode for ESP (EHC) in the meeting.
I.e., the current agenda for IPsecME
This call for adoptation has now finished, and we did got several
people supporting adopting this document as WG base document. Several
of those people also said that this is good baseline, but said we need
to work on the actual solution bit more, i.e., how many notifies are
needed and what is the
Bangkok meeting will be starting in few weeks. If you would like to
present anything in the IPsecME meeting (Wednesday afternoon I session
13:50-15:20 2018-11-07), please send request to us at
before end of next week (i.e., before
2018-10-21).
--
kivi...@iki.fi
Our new charter has been approved and that includes item:
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 initiator to determine why a given address
family is not assigned, nor
Heinrich Singh writes:
> Text saying that you would loose some privacy by using fixed number
> of SPI does not absolve your responsibility. It should not recommend
> that.
There is no requirement for SPI to be random and originally it was
written that way so implementations can use whatever
Ivo Sedlacek writes:
> RFC7296 states:
>
>
> >>The first two exchanges of messages
>establishing an IKE SA are called the IKE_SA_INIT exchange and the
>IKE_AUTH exchange<<; subsequent IKE exchanges are called either
>CREATE_CHILD_SA exchanges or INFORMATIONAL
Hugo Krawczyk writes:
> Why aren't these IKEv1 implementation defending against Bleichenbacher by
> hiding the nature of error (decryption error or authentication error) like
> what TLS 1.2 does [1]? Is this option documented in any of the IPsec/IKE
> documents? Is there a reason why it would not
Paul Wouters writes:
> I agree. I got limited information before publication (only about the
> weak PSK parts, not the RSA parts) and also voiced concerns about their
> IKEv2 claims.
>
> While in IKEv1 you have an oracle when the message can be decrypted only
> with the right PSK, in IKEv2 there
Valery Smyslov writes:
> after reading the paper I still don’t understand why authors
> mentioned IKEv2 there.
Of course they mention, just to get more exposure...
> Their example attack in Section 4.4 on (allegedly) IKEv2 in fact
> uses secondary responder supporting IKEv1 Public Key Encryption
RFC Errata System writes:
> The following errata report has been submitted for RFC7634,
> "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol
> (IKE) and IPsec".
>
> --
> You may review the report below and at:
>
Paul Wouters writes:
> >> 2) Are we correct with our assumption that you either end up on mutual
> >> authnull or with mutual authentication, or do people believe there
> >> is a use case for asymmetric authentication as well, in which case
> >> the responder could also send AUTH plus
Scott Fluhrer (sfluhrer) writes:
> "I put it in there because we reused an existing key update
> mechanism, and as that mechanism used nonces, we included them"
Updated to:
Valery: I like it. You outlined that you send Nonce payload for each
KE exchange, and not reuse one from
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=authnull -> authby=authnull,cert
Actually all
Valery Smyslov writes:
> No, I asked why each new KE in IKE_AUX incorporates its own nonce, instead
> of re-using
> nonces from IKE_SA_INIT. I have no problem with this if it is needed
> for security, my question was driven by curiosity.
I.e., so this would be (more?) correct:
Paul Wouters writes:
> 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
Yoav Nir writes:
> Since my message got lost in the overtime, I’ll say it again here.
Btw, I copied your comment from jabber to the minutes, as it should
have been releayed, but as our jabber relay was on the microphone, it
got skipped...
--
kivi...@iki.fi
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
If you find something that needs to be fixed send me email (I did add
Yoav's comments that did not get
Scott Fluhrer \(sfluhrer\) writes:
> > That we do not know until we know what those quantum computers can
> > really do... I have not seen anybody saying how many qbits you need to
> > break MODP-2048.
>
> It's about twice as many as you need to factor a 2048 bit composite;
> so about 4k
Scott Fluhrer (sfluhrer) writes:
> If the requirement for AES-256 is to handle the scenario "someone
> gets a quantum computer", then in that scenario, there is no
> realistic DH group size that is secure.
That we do not know until we know what those quantum computers can
really do... I have not
Valery Smyslov writes:
> my concern is that these MODP groups will have public keys of 1.5-2
> Kb in size, so it can make using them problematic in real world due
> to fragmentation issues...
In most of those cases the uses are not really road warriors or
similar setups, but more in a line of SGW
Linda Dunbar writes:
> There are two cases proposed by SDN controlled IPsec Flow Protection:
>
> - Case 1 is SDN controller only sending down the IPsec configuration
> attributes to End points, and End Points supports the IKEs and SA
> maintenance.
>
> - Case 2 is end points not supporting
When we greated RFC3526 [1] in 2003 we included 1536, 2048, 3072,
4096, 6144, and 8192 bit modp groups. I did also create 12288 and
16384 bit modp groups [2], but we did not include those as we assumed
they would be too slow for normal use.
Now sometimes there is requirement to align all security
I have now updated the IPsecME agenda for Monreal, and all but one of
the slides have been uploaded.
--
IETF 102 IPsecME WG meeting in Montreal
Wednesday, July 18, 2018
15:20-16:50 SAint-Paul/Sainte-Catherine
- Agenda bashing,
Mirja Kühlewind writes:
> Mirja Kühlewind has entered the following ballot position for
> charter-ietf-ipsecme-11-01: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory
I seem to have missed this email somehow.
Alissa Cooper writes:
> Alissa Cooper has entered the following ballot position for
> charter-ietf-ipsecme-11-01: No Objection
>
> --
> COMMENT:
>
Here is initial agenda for the Montreal. I would like to get everybody
who has any presentations to send the presentations to me before
Sunday, so I can upload them to meeting materials page well before the
meeting on Wednesday. Also if someone else still wants to have some
items on the agenda
Send us items you want to talk in Montreal IPsecME WG meeting. I will
make the agenda early next week.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Nico Williams writes:
> On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote:
> > Reading this thread now, I have few comments.
> >
> > [...]
> >
> > So I think the feature that we can use TLSA records in the split-dns
> > is very impor
Paul Wouters writes:
> You almost certainly will need to install some local webpki trust anchor
> to make use of your internal TLS servers reachable via the IPsec VPN.
>
> For example, to reach any of our internal redhat servers over HTTPS, I
> need to install a redhat internal CA into my
Suresh Krishnan writes:
> Suresh Krishnan has entered the following ballot position for
> charter-ietf-ipsecme-11-01: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory
Spencer Dawkins writes:
> --
> COMMENT:
> --
>
> I don't object to this proposed charter going for internal review, but do have
> one question.
>
> When looking
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
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
Michael Richardson writes:
> > It has to be a traffic selector.
>
> It has to be a traffic selector so that it can be selected (so do labeled
> IPsec SA), or not selected (do not do it). Any other mechanism
> (notification) can not be unambiguously rejected by a responder.
Not true.
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 that works - things get tricky (even
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
Ron Bonica writes:
> Hi Valery,
>
> I am thinking like this...
>
> - 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
Valery Smyslov writes:
> > Both good points. So, it appears that we have the following choices:
> >
> > - leverage IKE for exchanging probes and acks (But risk sending probes and
> > acks over a different path than
> > encrypted data)
> > - send probes and acks in-band. Try UDP probes first. If
While doing my IANA review on the document I found some small nits
about it. Here are my comments to the document:
--
Typo in abstract:
This avoids
sending the nonce itself, and savec in the case of AES-GCM, AES-CCM,
[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
Thanks for all the people writing minutes to the etherpad.
Here is the minutes for the IETF #101 IPsecME meeting:
--
IETF 101 IPsecME WG meeting in London
Friday, March 23, 2018
11:50-13:20 Park Suite
- Agenda bashing, Logistics
Pål Dammvik writes:
> Think I have discovered a small inconsistency in RFC 7296 with
> regards to the actions a node shall take if it received ESP packets
> with an unknown SPI.
Those cases are not exactly same. I.e., the section 1.5 explictly
talks about receiving ESP packet with unknown SPI.
Garcia-Morchon O, Oscar writes:
> From this point, I think that if the requirements (>64k) of those
> schemes need to be taken into account, then those should be taken
> into account now.
I think the best way to make them work is to keep the individual
payload length less than 64k, but QSKE (or
The final agenda and all the slides have now been submitted to the
datatracker meeting materials page. There might be updated versions of
the slides later, but at least you should be able to check initial
versions of them now.
I would really like to people to read at least following drafts before
Valery Smyslov writes:
> > No. The switch will be triggered immediately when the cluster / server
> > sends MOBIKE update using the 2nd ip address and does NOT include the
> > currently used IP address in the address list. If that message goes
> > through the client will start switch immediately,
Here is the preliminary agenda. If I missed any request for timeslot,
send me email ASAP, so I will check if I can add it...
We have quite a lot of presentations and it is possible we will not be
able to cover all of them (i.e., the ones in the end might be dropped
out).
I would like to get all
Valery Smyslov writes:
> > There is no timers in the RFC specified for any of these operations,
> > all of them are implementation details. This is something that will
> > NOT affect interoperability, but will affect how well your
> > implementation works. If this is important matter for your
> >
There was very little discussion about the "ready" parts of the
charter (one comment from Wouters, but no new text or explination why
"mesh" is different than host-to-host.
Additional items:
Item 1 responder MOBIKE
We had some discussion already on the list, and several people
If you want to present something in the IETF 101, send your request
for agenda slots to the us (WG chairs). We have already received two
requests (from Valery and Scott), but if there is something else you
think needs to be presented, please say so...
I will try to put up the agenda for the
Valery Smyslov writes:
> > The responder can simply do following describined in the RFC4555
> > section 3.6:
> >
> >There is one additional complication: when the responder wants to
> >update the address set, the currently used addresses may no longer
> >work. In this case, the
Valery Smyslov writes:
> 3. MOBIKE. In current MOBIKE only initial initiator can initiate change of IP
> addresses.
> If this problem is solved, then this is the best choice for load sharing
> clusters.
Mobike is symmetric in IKEv2 level. Either end can have multiple IP
addresses and can
Paul Wouters writes:
> 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
Yoav Nir writes:
> > The reason why we defined IKEv2 so that initiator provides identity
> > first, was that if responder provides identity first, then attackers
> > can make probe attacks and collect identities of the remote peers,
> > even when the IPsec is not currently in use. I.e., like we
Yoav Nir writes:
> > 2) The privacy of the initiator's identity in the presence of a man in
> > the middle attacker is not protected.
> >
> >Today an attacker with full control of the network can receive the
> >IDi/IDr sent by the initiator in the first AUTH packet. We should
> >add
This item does not have charter text yet, we do have text which
explains what the problem is, but I think it requires some
reformatting to fit as charter text.
The problem description is:
--
IKEv2 is currently vulnerable to the
This charter text was not ready during the IETF 100, we just had very
short description about the item, and I think most of the people did
not really understand it.
The proposed charter text for this item is:
--
Some systems
This item has draft (draft-boucadair-ipsecme-ipv6-ipv4-codes) which
quite well the needs and why this is to done, and I think we do
undestand the item itself, but the charter text was not covered in the
IETF 100 meeting, so we did not get consensus call done for it.
The proposed charter text is:
This is items we did not manage to reach full consensus in the IETF
100 meeting. There were concerns and questions why this is needed and
why it cannot be done with already existing methods (mostly redirect
etc, or updating the address lists).
The proposed charter text is
Here is the current proposed charter text about the items we managed
to agree in the IETF 100 meeting. I have left out the items we didn't
manage to have consensus, and I will send another email after this to
start discussion about them.
If you have comments (or objections) adding these new items
Paul Wouters writes:
> 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
mohamed.boucad...@orange.com writes:
> I was naively expecting a formal call to assess the
> interest/objections for each of the proposed items. Perhaps, I'm not
> the only one in that case.
That could have been another possibility, but as I was so busy between
the last IETF and now, I didn't
Paul Wouters writes:
>
> 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
mohamed.boucad...@orange.com writes:
> It seems that you missed this text for the address failure codes (Nov 13):
> https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html
Yes, as I wanted to get some more discussion about it in the mailing
list first. I have not seen any discussion
David Schinazi writes:
> Here is proposed charter text for the "Mitigating privacy concerns"
> section:
As there has not been any support for this item in the mailing list I
do not think we will be adding it in the charter this time.
> IKEv2 is currently vulnerable to the two following privacy
While approving the IANA expert request for this document I noticed
some things that might require some fixes to the draft:
--
In section 1.1 (which will be removed) there is typo in PPK_SUUPORT.
--
In section 3 it would be better to use the same format than what is
used in the RFC7296 when
While approving the IANA allocations I re-read the document again, and
I have some more comments that might make the document more
understandable.
--
In section 4.1 there is example of example.com, but it would be better
to put quotes around it it, i.e., change
A Fully Qualified Domain
Yoav Nir writes:
> I don’t see anything wrong with the suggestion (it’s just adding “to indicate
> NONE” in the last
> sentence). However:
I think it is pointless change, and there is no need to give name for
the number we use when we do not have protocol identifier, when it is
used in exactly
Paul Wouters writes:
> On Mon, 22 Jan 2018, Tero Kivinen wrote:
>
> [ added i...@ietf.org to get a general discussion on this, as it seems
> this is a procedural issue not specific to the WG ]
You are trying to follow wrong procedure. There is NO early
allocations for expert revie
Paul Wouters writes:
> 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,
Paul Wouters writes:
> See:
> https://tools.ietf.org/html/rfc7321
>
> https://tools.ietf.org/html/rfc8221
See
https://datatracker.ietf.org/doc/rfc7321/
https://datatracker.ietf.org/doc/rfc8221/
and you can see that the information is already correct.
> 8221 states properly:
>
>
Paul Wouters writes:
> 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
Paul Wouters writes:
> We could use the IDr payload in IKE_AUTH for that, using an ID_KEY_ID
> type. But we would also really like to use the IDr payload on the
> initiator to convey to the responder which FQDN we are expecting, so a
> responder could use a different key for each FQDN it is
I put the candidate charter text to the wiki. This includes the
changes in the first two paragraphs, removes items already done, and
list of new items. I have not yet added the items that came too late
to have charter text bashed in the meeting to the wiki.
For those items which do not have text
Valery Smyslov writes:
> > Why would you make multiple encodings formats for the same algorithm?
> > And if so why should we allow that in IPsec. We do not allow prehashed
> > formats of the Ed25519 and Ed448 because we do not want to have
> > multiple formats for the same thing.
>
> If tomorrow
Valery Smyslov writes:
> > If I remember right on discussion about the different elliptic curve
> > algorithms, the situation was same there, i.e., even if you could use
> > the same key for different algorithms, it is considered bad idea...
>
> We are not talking about different algorithms.
Valery Smyslov writes:
> > This is the reason why the RFC7427 only negotiates the hash algorithm,
> > and the section 5 of the RFC 7427 gives several ways of solving this
> > issue without doing protocol changes.
>
> No, section 5 is about a different problem: how to select
> a proper
Valery Smyslov writes:
> Hi Tero,
>
> how about:
>
> 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
Valery Smyslov writes:
> How about the followingy last sentence:
>
> The solution will allow post quantum key exchange to be
> performed in parallel with (or instead of) the existing Diffie-Hellman key
> exchange.
Updated to match to that.
--
kivi...@iki.fi
I have now received following items for consideration for charter
(includes old items not finished in the current charter):
--
IKEv1 using shared secret authentication was partially resistant to
quantum computers. IKEv2 removed
Sahana Prasad writes:
> We could consider adding this item to the working charter :
>
> Explicitly negotiating different RSA versions (Specific case) :
If you want it to be considered as charter item, please provide text
suitable for charter.
--
kivi...@iki.fi
Waltermire, David A. (Fed) writes:
> This message starts a Working Group Last Call (WGLC) for
> draft-mglt-ipsecme-implicit-iv-04.
>
> The version to be reviewed can be found here:
> https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt.
>
> Please send your comments, questions, and
We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our
main agenda item will be the rechartering text, i.e., our charter will
expire by the end of year, and we have most of our chartered work
already completed, or almost finished, so we need to decide what new
items (if any) we take
Paul Wouters writes:
> Did it not get marked as replacing the fluhrer draft ? Now there is
> no diff available. Can that still be fixed?
Not automatically, and I was in progress of doing that, but it took me
few minutes to find out how to do it properly... It should be marked
as replacing it
Paul Wouters writes:
> > for 8, 12, 16 octet versions came to be 18, 19, and 20, and the number
> > 17 which was most likely allocated for the 4 octet ICV was marked as
> > reserved.
>
> Except it is marked unassigned, not reserved. So one could use this
> number in the future. I for sure have
Michael Richardson writes:
> Why did we skip
> IKEv2_UNASSIGNED_17 = 17,
>
> for IKEv2 Encryption Transforms?
>
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
The original draft-ietf-ipsec-ciph-aes-gcm [1] had four differnet ICV
lengths: 4,
Black, David writes:
> Well, RFC 5282 actually prohibits the responder from selecting that
> combination, but requiring separate proposals for combined-mode and normal
> ciphers is a cleaner and simpler approach.
Yes, and RFC5996 restricted that even more, saying that you need to
use separate
Bruckert, Leonie writes:
> Additionally, it would be nice to also protect the identities i.e.
> to make the AUTH exchange quantum resistant. Particularly with
> regard to the PPK draft which doesn’t assure this.
As we discussed earlier, some kind of pseudonym system might be better
for this,
Paul Wouters writes:
> Received PPK_SUPPORT Have PPK PPK MandatoryAction
> --
> Yes No *Standard IKE protocol
> Yes Yes *Include
Michael Richardson writes:
> I don't think we need to do this.
> I think that unknown transform types will be ignored by compliant
> implementations.
Nope. It will ignore unknown transform IDs for each known transform
type, but it MUST understand each transform type, and if it does not
understand
Daniel Van Geest writes:
> 1) QS SA Negotiation
>
> When negotiating a QS SA, it’s not enough to negotiate QS key
> agreement algorithm(s), one also has to ensure that the algorithms
> selected by the other transform types are also QS.
All of these kind of issues are really policy matters, thus
Cen Jung Tjhai writes:
>>And I think if the IKE_SA_INIT messages grow too large with QSKE,
>>then it’s better to develop generic fragmentation mechanism for
>>IKE_SA_INIT, rather than making it specific for fragmenting QSKE
>>blobs. Generic mechanism would allow to reuse it in case we’ll have
>>to
Valery Smyslov writes:
> It is not clear for me (and I raised this concern in Prague) why do
> you use QSKE as an additional Key Exchange mechanism instead of
> replacing DH KE with it? We’ve been being told by cryptographers
> that conventional public key cryptography won’t provide security in
>
Here are the minutes of the meeting (thanks Yaron), if you have fixes,
additions etc to them send them to me. I will post these to the
meeting materials next week.
--
Minutes of the IETF 99 IPsecME WG meeting Prague 2017-07-21.
Rafa Marin-Lopez writes:
> I.e. any TLA would love to get their hands on all the traffic keys in
> one location, and then be able to decrypt any traffic going inside any
> of the IPsec tunnels.
>
> If controller only has the PSKs or similar to do the authentication
>
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 this case, since an attacker, if attack is successful,
> will gain all the keys for the whole system.
And it is
RFC Errata System writes:
> The following errata report has been submitted for RFC7296,
> "Internet Key Exchange Protocol Version 2 (IKEv2)".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5056
>
>
Yoav Nir writes:
> But since Tommy’s happy with tearing down the connection after one invalid
> SPI, that solves the problem nicely.
I do not think we want to do that. There are valid cases where we
might get unknown SPIs, so tearing connection down after one of those
is not good solution.
> By
301 - 400 of 1088 matches
Mail list logo
