In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the
document lists operations which needs to be done when handling the
notification. The process seems otherwise quite good, expect the error
handling seems to be bit drastic.
It currently says that if the authenticated identites are
Valery Smyslov writes:
> There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number
> and Total Fragments. But Total Fragments field plays a dual role if
> peer uses PMTU discovery - i.e. tries several fragment sizes.
> In this case Total Fragments allows to distinguish between fr
# Copyright (c) 2013 Tero Kivinen
# All Rights Reserved.
##
# Program: song-crack.pl
# $Source: $
# Author : $Author: kivinen $
#
# (C) Tero Kivinen 2013
#
# Creation : 16:04 Oct 9 2013
I tried to read this before the interm meeting, but found out that it
would require me to read it trough several times before I could really
understand it.
The basic architecture is simple, we have some trusted third party,
ADS which stores all information and ADC devices talk to it and gets
some
Paul Wouters writes:
> On Wed, 9 Oct 2013, Tero Kivinen wrote:
>
> > For example the
> >
> > o Check message validity - in particular, check whether values of
> > Fragment Number and Total Fragments in Encrypted Fragment Payload
> > are valid
While we are updating the algorithm requirements for the ESP and AH, I
think we should also update the RFC4307 too at the same time, as a
separate document.
I think the changes we would like to do there are:
Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD.
Upgrade Diffie-Hellman
Yaron Sheffer writes:
> I'm even more worried that if we use small fragments, reliability will
> deteriorate. Because we do not have per-packet acknowledgement, and so
> if any fragment is dropped, the whole message must be resent. This is
> probably a greater risk in mobile networks.
The fix t
Paul Wouters writes:
> which seems to imply 768 MODP group is "MAY". Which is confirmed in RFC
> 4109. So I think we should also update 768 MODP group to MUST NOT.
I agree on that. I thought we deprecated that already in the RFC4306
by saying:
-
Yoav Nir writes:
> > I.e. the INVALID_SYNTAX notification is considered fatal in both
> > peers, meaning that IKE SA is deleted. In this case this will cause
> > the OLD IKE SA to be deleted. I do not think we want to be that to
> > happen. Perhaps something less fatal error message would be better
I made new version of the RFC5996bis (yes, I am more than month too
late from my original time-estimate).
This version removes the Raw RSA public keys, adds reference to the
5996, 6989 and 4945. Cleans up IANA Considerations section, and adds
note to both to the abstract and Introduction that this
Michael Richardson writes:
> I followed the reference to draft-ietf-tls-oob-pubkey-07, which I read.
> I would like to suggest that section 3 more quickly refers to the
> tls-oob-pubkey Appendix A, and that it say something like:
>
>In order to provide a simple and standard way to indicate the
Paul Wouters writes:
> On Thu, 17 Oct 2013, Tero Kivinen wrote:
>
> > I made new version of the RFC5996bis (yes, I am more than month too
> > late from my original time-estimate).
> >
> > This version removes the Raw RSA public keys
>
> Is that the old versio
Johannes Merkle writes:
> draft-kivinen-ipsecme-signature-auth-01 is about to expire. Given
> the current discussions on potential backdoors in NIST
> curves (don't want to participate in these conspiracy theories
> though), signature algorithm flexibility may be even more
> desirable.
As it exp
Title : Minimal IKEv2
> Author(s) : Tero Kivinen
> Filename: draft-ietf-lwig-ikev2-minimal-01.txt
> Pages : 44
> Date: 2013-10-17
>
> Abstract:
>This document describes minimal version of the Internet Key Exc
Valery Smyslov writes:
> The problem, that the draft is not solving, is the situation,
> when one of the peers has more than one private key, each
> for different signature algorithm. This may happen if in deployed
> VPN there is a need to move from one signature alg
> to another (for any reason, f
Valery Smyslov writes:
> > And you can always retry when you notice that you get authentication
> > error after using private key, provided you have multiple types of
> > keys.
>
> In general you can't if it is responder who selected wrong key.
That is something I realized on our way home, but i
Pekka Riikonen writes:
>
> The ASN.1 used here are the same ASN.1 which is used in the
> AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The
>
> It should specify encoding rules, even though it references RFC5280. So
> this could say something like:
>
> The ASN.1 u
I have reviewed this draft again.
I tihnk we should add bit more in to the introduction. I.e explain the
common case for this protocol is to fragment exactly ONE message pair
(IKE_AUTH), and those messages are most commonly around 500-3000 bytes
long.
For example to do proper PMTU for sending exa
Yoav Nir writes:
> 3. While the TCP stack has access to these ICMP packets and the
> PMTU that they convey, a userspace IKE daemon usually doesn't. See
> [1] for how people suggest doing it in C#.
Actually for example our code tries to get ICMP messages for IKE
packets, mostly so that we can ma
Valery Smyslov writes:
> Draft introduces IKE-level fragmentation to avoid IP fragmentation
> whenever possible and to only let it be if it is impossible.
Actually the first preference is to use IP fragmentation, and if that
works, it is what we use, and we do not try IKE fragmentation at all.
Onl
Valery Smyslov writes:
> >> > And you can always retry when you notice that you get authentication
> >> > error after using private key, provided you have multiple types of
> >> > keys.
> >>
> >> In general you can't if it is responder who selected wrong key.
> >
> > That is something I realized
Paul Wouters writes:
> 3.3.1. Proposal Substructure
>
>
> 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | 0 (last) or 2 | RES
Valery Smyslov writes:
> > Yes, it only works if the initiator picked wrong key. On the other
> > hand as I pointed out there are already 3 ways for the responder to
> > pick right key (optional IDr in initiators IKE_AUTH request, CERTREQ,
> > and AUTH payload sent by the initiator).
>
> And none
Michael Richardson writes:
> Yoav Nir wrote:
> >>> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+
> >>> to SHOULD.
> >> this is the only one which I didn't understand.
> > Which one? There's two parts there.
> True.
> So, the "_CBC" to "_XCBC" is either a typo
Michael Richardson writes:
> For a given IPsec SA, they want to overwrite/force/set the DSCP to a
> particular value. It will not depend upon the traffic goes into it
> (but, the SPD selectors may quite specificly pick the traffic).
If I think RFC4301 already requires that. I.e. it requires
imple
While we are working on the ESP, AH, IKEv2, and Architecture
documents, I think we should do also the easy ones:
- RFC2451 "The ESP CBC-Mode Cipher Algorithms"
- RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for
Internet Key Exchange"
- RFC3948 "UDP Encapsulation of IPsec ESP Pa
Yaron Sheffer writes:
> > - RFC2451 "The ESP CBC-Mode Cipher Algorithms"
>
> This is nominally a generic document, but it's really about a list of
> specific algorithms, none of which is in wide use today (we are trying
> to phase out 3DES and in general 64-bit block algorithms). This document
Mike Sullenberger (mls) writes:
> As for scaling, we already have DMVPN networks of 1+ nodes and
> looking at building networks of 4+ nodes. In many cases
> customers have multiple subnets behind each node, therefore with
> just IPsec I would need to have multiple SAs/encryption between the
Yaron Sheffer writes:
> IIRC we published RFC 5903 using the old code points because there was
> no objection, i.e. no indication that people had deployed pre-errata
> 4753. Whether this was the right thing to do or not is not very
> interesting now.
There was very strong objection, at least fr
Yoav Nir writes:
> The VPN products from Cisco, Juniper and Check Point support them,
> as well as both StrongSwan and OpenSwan. I'm sure there are others
> as well.
But which version of their products support which version of the ECC
groups? For example I have no idea which version our toolkit,
Paul Hoffman writes:
> > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same
> > IANA values for two different non-interoperable uses of the groups, I
> > cannot say there is enough interoperable use for that RFC.
>
> Nor can you say that there is *not* enough interoperable use.
[I am now doing these editorial changes, and I will be sending
separate emails for each of them, just so I can keep track of what is
changed and where, and you can complain if I miss or misinterpret
something (but do not complain about missing changes before I send
email that I have processed all o
Valery Smyslov writes:
> 1. Section 1.6 Requirements Terminology is placed far from the begining
> of the document and all the requirements words, along with terms
> from RFC4301 etc. are used before they are formally introduced.
> I don't think it is appropriate for standards track doc
Valery Smyslov writes:
> 3. Page 10.
>"HDR contains the Security Parameter Indexes (SPIs), version numbers,
>and flags of various sorts."
>
> Not mentioned Message ID, Exchange Type (and Next Payload and length,
> but they are not very important here). I suggest to change:
>
>"HDR con
Valery Smyslov writes:
> 4. Page 11.
>"At this point in the negotiation, each party can generate SKEYSEED,
>from which all keys are derived for that IKE SA."
>
> Term SKEYSEED pops up from nowhere. No reference is gived and
> even no word is explained what is it all about. First-time reade
Valery Smyslov writes:
> 5. Page 14, 15 and 16
>"The responder replies (using the same Message ID to respond) with the
>accepted offer in an SA payload, and a Diffie-Hellman value in the
>KEr payload if KEi was included in the request and the selected
>cryptographic suite includes t
Valery Smyslov writes:
> 6. Page 19.
> "The recipient of this notification cannot tell
>whether the SPI is for AH or ESP, but this is not important because
>the SPIs are supposed to be different for the two."
>
> Why "is supposed to be different"? RFC4301 clearly states:
> "For a u
Valery Smyslov writes:
> 7. Page 31.
> Phrase "(see Section 2.6)" actually references the same section. It should
> either
> be removed or corrected.
Changed:
In the first message of an initial IKE exchange, the
initiator will not know the responder's SPI value and will
t
Valery Smyslov writes:
> 8. Page 31.
> "However, if the responder sends a non-zero
>responder SPI, the initiator should not reject the response for only
>that reason."
>
> Should here "should not" be "SHOULD NOT"?
If I correctly parsed exchanges in the mailing list concensus was to
sk
Valery Smyslov writes:
> 9. Page 49.
> "There are two types of EAP authentication (described in
>Section 2.16), and each type uses different values in the AUTH
>computations shown above. If the EAP method is key-generating,
>substitute master session key (MSK) for the shared secret
Valery Smyslov writes:
> 10. Page 51.
> "As described in Section 2.2, when EAP is used, each pair of IKE SA
>initial setup messages will have their message numbers incremented;
>the first pair of AUTH messages will have an ID of 1, the second will
>be 2, and so on."
>
> Should be:
Valery Smyslov writes:
> 11. Page 52:
> "A single CHILD_SA negotiation may result in multiple Security
>Associations."
>
> Should be:
>
>"A single CREATE_CHILD_SA negotiation may result in multiple Security
>Associations."
Changed:
A single CHILD_SA negotiation may resul
Valery Smyslov writes:
> Just came across one more small editorial issue in RFC5996.
> Page 73, description of "Next Payload" field, sentence
>
> In the header of an Encrypted payload, the Next Payload field is set
> to the payload type of the first contained payload (instead of 0);
>
Paul Wouters writes:
> Implementors still need to name that struct. Instead of everyone
> coming up with their own name it would be good to have a standard
> name for it.
I do not think it is that important to have names, I am good at
inventing better names than what they use in standards :-)
> S
Yaron Sheffer writes:
> I think RFC 6989 (additional tests when reusing DH values) should be a
> normative reference,
There is not a single group defined, or even mentioned in the
RFC5996bis that requires those checks, so I think it can be
informational. For documents specifying groups that requi
Paul Hoffman writes:
> Slight editorial clean-up on the new wording:
>
> o Last Substruc (1 octet) - Specifies whether or not this is the last
> Proposal Substructure in the SA. This field has a value of 0 if this
> was last Proposal Substructure, and a value of 2 if there are more
>
I am now done through my queue of RFC5996bis changes. If someone has
still something, that wants to argue about those I didn't include, do
it now.
I will be submitting new draft version soon (tomorrow).
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ie
I updated the RFC5996bis draft to include the editorial changes sent
to the list (all changes sent up To tuesday).
I also updated the signature authentication draft by adding the
section about the public key selection methods, and I also added the
binary objects for the commonly used signature ASN
Gandhar Gokhale writes:
> As defined in this document, UDP encapsulation of ESP packets is
> written in terms of IPv4 headers. There is no technical reason why
> an IPv6 header could not be used as the outer header and/or as the
> inner header.
Of course we hope nobody every makes NATs for IPv6,
Gandhar Gokhale writes:
> Thank you Tero. It clarifies my doubt.
> However, with a SHOULD clause it's not quite apparent in the RFC that
> this is just an 'optimization' for IPv4. And since the RFC claims that
> there is no technical reason for this not to work with IPv6 it becomes
> incompatible s
Johannes Merkle writes:
> Tero Kivinen schrieb am 14.11.2013 01:25:
> > I also updated the signature authentication draft by adding the
> > section about the public key selection methods, and I also added the
> > binary objects for the commonly used signature ASN.1 objects. I
Yaron Sheffer writes:
> +1 on making single-DES CBC a MUST NOT.
Agree on that. (And I still need to read the whole document, I am way
too much behind with my IPsecME WG draft reading).
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://ww
Valery Smyslov writes:
> I've posted new version of the NULL Auth Method draft.
> It addresses comments received from Yaron Sheffer and Paul Wouters.
Ah, I just managed to read the -00 version... Oh well, reading diffs
next...
Anyways I think the document is in quite good shape, I think the
secti
Valery Smyslov writes:
> The draft lists the following trasforms based on AES cipher:
>
> AES-GCM
> AES-CCM
> AES-CTR
> AES-128-CBC
> AES-GMAC
> AES-XCBC-MAC-96
>
> All these transforms, except for AES-XCBC-MAC-96,
> allows to be used with different key lengths - 128, 192 and 256 bits.
> It looks
First of all, I am really dubious whether this is needed. When I
started reading this, I first assumed, ok, it is used to transfer some
data between two nodes from userland to userland without any need for
kernel IPsec stack, or some configuration / policy data that is needed
before the ESP SA can
I have read this document, and I think it is getting ready. I have
some nits for it, but they are just typos and similar.
Nits:
--
In appendix A:
The attacker could infrequently emit forged but looking valid fragments
Paul Wouters writes:
> > Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
> > ignored", and I think that is again bad idea. I think logging and
> > auditing the ID for problem solving purposes is good idea even if it
> > does not have any meaning for the authentication. I.e. a
Paul Wouters writes:
> On Tue, 4 Mar 2014, Valery Smyslov wrote:
>
> > I agree this may chocke some implementations. The idea was that
> > if implementation notice that Auth Method is NULL, it must
> > not parse ID Payload at all. But I understand that depending
> > on the order in which payloads
Paul Wouters writes:
> On Tue, 4 Mar 2014, Tero Kivinen wrote:
>
> >> I have actually thought about a mode where we scramble the order or
> >> payloads just to see which implementations would die :P
> >
> > That only works for RFC5996 version, RFC4306 versi
In the section 4. Protocol Overview, the draft says:
The current IKE_SA becomes the old IKE_SA and the newly negotiated
IKE_SA becomes the new IKE_SA.
What the draft does not specify what happens to the Child SAs present
on the old IKE SA. Are they moved to the new IKE SA or are they
stayin
In section 2 it says:
Note that IKEv2 and IPsec session do not need to be on the same node
as IKEv2 and IPsec context are different.
This is not so easy. The RFC5996 says:
--
2.4. State Synchronization and Connection Time
Daniel Palomares writes:
> So, would you think it is a good idea to add this information to the draft (I
> mean the new requirements when IKE_SAs and IPsec_SAs are on separated nodes)?
> ... Or instead, would you think it would be good to ignore how applications
> are managing their IPsec_SAs and I
Yoav Nir writes:
> Hi
>
> draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms:
>
> 1. chacha20 as a stand-alone cipher
> 2. Poly1305 as a stand-alone MAC
> 3. ChaCha20-Poly1305 as an AEAD.
>
> Some people in the room said that we should only do the AEAD and skip the
> sta
RJ Atkinson writes:
> > If that's what the WG wants, great. In me reading the
> > list as a document author, I don't see people agreeing with that.
>
> If this I-D is NOT addressing all IPsec use cases, then why isn't
> this I-D titled the "IPsec VPN Requirements" document ?
I think you are wrong
Paul Wouters writes:
>
> According to RFC 3554 (SCTP with IPsec):
>
> IANA has assigned number 12 for ID_LIST (defined in Section 3) in the
> "IPSEC Identification Type" registry
>
> which matches:
>
> http://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-regis
Yoav Nir writes:
> I assume you mean that you don’t sign with public keys. Replacing
> “sign” with “validate” makes for a strange sentence, because the
> sentence is about sending (and presumably signing) rather than
> receiving (and validating).
>
> How about:
> “If multiple certificate are sent
I am making new version of the rfc5996bis, so going through old emails
too...
Paul Wouters writes:
> On Thu, 17 Oct 2013, Tero Kivinen wrote:
>
> [forgive me if already reported]
>
> Section 3.1 states:
>
> o Major Version (4 bits) - Indicates the maj
Praveen Sathyanarayan writes:
> I agree, it is a corner case. Example, out of 5000 tunnels, may be we will
> see 10 to 15 tunnels end up in this scenario. So memory/resource is not a
> concern.
There are two cases: Your implementation is very limited, and support
very few Child SAs and cannot cop
vijay kn writes:
> Praveen/Ahmad,> Some vendors don’t support Reauth. In this case what
> to do?
There is no specific need for reauth on the protocol level. You create
new IKE SA, you create new Child SAs, you delete old IKE SA.
Everything is just standard IKEv2 and all implementations support
th
Black, David writes:
> In looking for something else, I ran across a minor thinko in the
> rfc5996bis draft that was inherited from RFC 5996.
>
> Section 3.14, Encrypted Payload, 4th paragraph:
>
>When an authenticated encryption algorithm is used to protect the IKE
>SA, the construction
Steve Baillargeon writes:
> - in the section 2.9 on Traffic Selector Negotiation, I think it
> will be good to have a few sentences about the relation (or lack of)
> between traffic selector and static routing especially when dealing
> with AH/ESP tunnel mode. As far as I know many implementers wil
Valery Smyslov writes:
> > I see an interop issue where a transform for a child sa is rejected in
> > the initial exchange because of a mismatch in the modp transform.
>
> Our implementation requires that the list of DH groups for
> IKE and IPsec be the same in case of IKEv2.
Or you could remove
Johannes Merkle writes:
> Nice work, the wording is really improved. However, I still have two
> comments:
>
> 1. The wording in A.4 is confusing.
>
>With RSASSA-PSS, the algorithm object identifier is always id-RSASSA-
>PSS, but the hash function is taken from the optional parameters, a
Kostas Pentikousis writes:
> (adding ipsec folks in CC)
I quickly read this document and I think it needs much broaders review
from the IPsec people. This document is using internal IKEv2 keying
material outside IKEv2 SA context, meaning it can cause problems with
the actual security of the IKEv2
Yaron Sheffer writes:
> This might sound like a nit, but we have this text in the draft, as
> a use case for null auth:
>
> "User wants to get some simple action from the remote device. Consider garage
> door opener: it must authenticate user to open the door, but it is not
> necessary for the use
Les Leposo writes:
> > The iphone (which is only rumored to do IKEv2 with iOS8 likely to be
> > released in September this year) currently has a
> > terrible record of continuously re-establishing connections. Like
> > whenever the screen saver hits it will tear down the tunnel. With
> > an always-
Paul Wouters writes:
> > I.e. the recent connections table has list of IP-address who have
> > tried to connect to you, but have not yet authenticated, i.e. either
> > real devices in the middle of authentication, or attackers. The real
> > devices in the middle of authentication will not try to re
Les Leposo writes:
> have you overlooked the issue of nat mappings?
Nope.
> ipsec nat keepalives are very useful for keeping nat mappings alive,
> and in a world full of all sorts of nat devices (some behaving
> reliably and others not), one would have to use low keepalive
> interval... like 10-6
Paul Wouters writes:
> On Tue, 19 Aug 2014, Tero Kivinen wrote:
>
> >> You would need the port number too to support multple clients behind the
> >> same NAT router, upon which the attacker can then use multiple ports too.
> >
> > No need for port number.
Pål Dammvik writes:
> One of the differences between RFC 5996 and 4306 is in the rekeying
> where it's stated in RFC 5996 section 2.8:
>
> "Note that, when rekeying, the new Child SA SHOULD NOT have
> different Traffic Selectors and algorithms than the old one."
>
> Additionally in section 1.3.3
Johannes Merkle writes:
> you haven't responded to my objection yet. Please let me know if you
> think that I am mistaken; otherwise the example
> should be corrected.
I have not have time to come back to this draft yet, I was still
supposed to be on vacation for last week and this week, but I ha
Valery Smyslov writes:
> if new version of draft-kivinen-ipsecme-ikev2-rfc5996bis is issued,
> then it is also possible fix a typo I've come across.
>
> Section 2.8.1, second para:
>This form of rekeying may temporarily result in multiple similar SAs
>between the same pairs of nodes. When
Avishek Ganguly writes:
> I have questions regarding use of NO_PROPOSAL_CHOSEN and
> INVALID_KE_PAYLOAD in
> IKE_SA_INIT exchange in RFC 5996 IKEv2.
>
> According to
>
> "Section 3.10.1. Notify Message Types
>
> NO_PROPOSAL_CHOSEN 14
> None of the proposed crypto su
dharmanandana pothulam writes:
> We are facing one IKEv1 interop issue. The issue is that Responder
> (checkpoint SeGW) not retaining the transform numbers received from
> the initiator (huawei base station), SeGW replies with its own
> transform number.
IKEv1 was obsoleted by IKEv2 in 2005, you s
Yaron Sheffer writes:
> This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply
> here. Note that it only applies in specific cases, and for specific EAP
> methods.
>
> Yes, we should have updated the text in RFC 5996 to refer to 5998, but
> we forgot. Sigh.
Hmm.. I hope this
Yaron Sheffer writes:
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a
> WG document. Please respond to this mail with a Yes or No and a short
> rationale, at latest by Friday Sep. 12.
I have not really had time to concentrate on this topic yet, but I
think this kind of e
Yaron Sheffer writes:
> This is a call for adopting draft-nir-ipsecme-puzzles-00 as a WG
> document. Please respond to this mail with a Yes or No and a short
> rationale, at latest by Friday Sep. 26.
I think this problem is something we should consider, i.e start
working on the solution to it. I h
Tero Kivinen writes:
> Yaron Sheffer writes:
> > This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply
> > here. Note that it only applies in specific cases, and for specific EAP
> > methods.
> >
> > Yes, we should have updated
Valery Smyslov writes:
> In Section 3.8 (Authentication Payload) the description
> of the 3-octet RESERVED field is absent. I think it is a typo,
> as in all other cases, when reserved field is present
> in payload (KE, ID, TS, CP), its description is given.
Fix sent to the RFC editor during the A
Valery Smyslov writes:
> 1. Section 3.15.1:
>
>o APPLICATION_VERSION - The version or application information of
> the IPsec host. This is a string of printable ASCII characters
> that is NOT null terminated.
>
> "NOT" is uppercase. Although it might be an intention to ephasise
Valery Smyslov writes:
>o Selector Length - Specifies the length of this Traffic Selector
> substructure including the header.
>
> No indication of how "Selector Length" (it is 2 octets) should be
> treated.
Fix sent in for the rfc-editor...
--
kivi...@iki.fi
___
Michael Richardson writes:
> Yoav Nir wrote:
> > One proposal that I kind of liked (and I’m sorry I’ve forgotten who
> > suggested it) was to relegate the puzzle to a second line of defense,
> > through the use of some kind of anti-dos ticket. The ticket would be a
> > bearer token
Yoav Nir writes:
> > Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for
> > those clients coming back.
> >
> > I.e if you resume old existing session then you do not need to do
> > puzzle... And after the resume, the ticket is usually changed again,
> > so the ticket would always
Michael Richardson writes:
> I think that this is the best process; I think we need to think about the
> problem deeper. It would be nice if it could be made to work; but I suspect
> that may be equivalent to the CAPTCHA problem.
I do think the problem is easier than that...
I think the solutio
Got following request form IANA, and approved it. This is just for
information in case someone is interested.
Amanda Baber via RT writes:
> We have another request for an IKEv2 Configuration Payload Attribute
> Type. If this is OK, how should we fill in the "Multi-Valued" and
> "Length" columns?
Johannes Merkle writes:
> thanks for updating the document. However, I'm not sure the first
> issue is solved.
Sorry this has taken so long, having the IEEE, IETF, Vacation and
RFC5996bis to taken care of before getting back to this draft.
> Tero Kivinen wrote on 20.07.2014 21:0
Michael Richardson writes:
>
> Tero Kivinen wrote:
> > 3) Client can also be smartphone, i.e. device which have quite a lot of
> > CPU power and/or memory, but does not want to use it as it would
> > increase the power usage so much that the battery life w
Nico Williams writes:
> On Sun, Oct 05, 2014 at 11:22:29PM +0300, Yoav Nir wrote:
> > Now the responder has two options:
> > (1) delete the entry in the half-open SA database, or
> > (2) store the derived key, and keep the half-open SA another 9.5 seconds.
> >
> > (2) has the disadvantage that t
James Hulka writes:
> Dear IPsec Working Group,
>
> there is a race condition in the current IKEv2 protocol when 2 site
> peers are configured to automatically establish a IPsec tunnel.
>
> Both peers can successfully initiate the IKE_SAs which results in
> each peer having 2 options available f
Paul Hoffman writes:
> If you agree with the need to standardize this usage, and believe
> that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good
> starting place for that standardization, and are willing to review
> and contribute text to the document if it is adopted by the WG,
> pleas
601 - 700 of 1364 matches
Mail list logo
