Valery Smyslov writes:
You are describing a situation where the server simply has
multiple queues, I think. One for 20 bits, and probably one for
each of 19,18,17,16, and then one for all solutions 16, including
not supporting puzzles at all.
Yes, but the queues are virtual, the server
Valery Smyslov writes:
I also had some concerns on the variance of the times. But then
another thought came to me. Let's look on this issue from the other side.
The responder will use puzzles only when it feels that it is under attack.
It means, that there are a lot of (thouthands, tens of
Valery Smyslov writes:
I don't see how this can be done without breaking existing
implementations, and therefore I am unhappy with the new sentence in
-03, Another example is EAP authentication when the client identity in
ID payload is not used. A responder that receives a new, unknown
Valery Smyslov writes:
Nope. The IKE ID payloads needs to be used, and the EAP identity
reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16):
Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder
Paul Wouters writes:
On Mon, 19 Jan 2015, Tero Kivinen wrote:
In security considerations section there is text:
Un-authenticated IKE
sessions MUST only attempted when authenticated IKE sessions are not
possible for the remote host and the only
Valery Smyslov writes:
Hi Tero,
thanks for your detailed review. Please see inline.
I commented only the issues where we disagree with Paul.
On the other hand same section says that ID_NULL SHOULD only be used
with NULL authentication method. In which scenarios do you think
ID_NULL
Valery Smyslov writes:
Valery suggests sending liveness checks to all IKE SA's that used
AUTH_NONE.
I suggested sending liveness checks only to those IKE SA's that used
the same IP address, thus limiting the scope to a more likely pool
of possible orphaned SA's by a remote that
Paul Wouters writes:
What is the purpose of installing a zillion unauthenticated protoport
specific IPsec SA's over a single one? The abuse case here for
unauthenticated clients is clear, thousands of SA's per IP in the
botnet.
I do not think anybody wants to install or allow zillion
In section 2.2. it still says that ID presented MUST be ignored.
I think this needs to be changed to SHOULD.
There are valid cases where we would like to use the ID, for example
we might want to assign the same ID same IP-address every time, just
to make things easier. This does not mean we
Paul Wouters writes:
That was partially because Valery and I didn't fully agree. Which means
it might not belong in this document. Initial Contact is addressed in
the document already in its own section. The question for example is
about CREATE_CHILD_SA. Which comes back to your point below
Shota Nagayama writes:
Though I replied that fallback mode might be treated as local policy
and not to be negotiated at the beginning of IKE, now I notice a
difference between fallback mode and other local policies, if my
understanding is correct. In current IKE, after establishing the
first
Paul Hoffman writes:
Greetings again. The Clone IKE SA proposal tries to optimize IKE
SA setup in cases where VPN gateways have multiple interfaces and
want to establish different SAs on the different interfaces without
having to repeat the IKE authentication. Instead, they could clone a
Paul Wouters writes:
On Thu, 27 Nov 2014, Valery Smyslov wrote:
I think that the mechanism it describes is useful and could be used
as a building block for several solutions. For example,
it can be used in load-sharing scenario when there are
some gateways with different IP addresses,
Michael Richardson writes:
Tero Kivinen kivi...@iki.fi 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 will be
shortened
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 the
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 for
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:02:
Changed
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?
===
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 solution
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 be fresh.
Michael Richardson writes:
Yoav Nir ynir.i...@gmail.com 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
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
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
the
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
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
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 the text in RFC 5996 to refer to 5998, but
we forgot. Sigh
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
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 does
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
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 suites was
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
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 had
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 (that
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-60s.
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. If server is under attack just block / slow
down
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-on
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 user to
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
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, and
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 will
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 of the
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 cope
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
that
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, the
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 major version of the IKE
protocol
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-registry-31
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 there.
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
stand-alone
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
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
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
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. at least
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 are
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 version are allowed to
reject packets which have
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
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 strange to
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
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
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. If
someone has any way
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 set
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,
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
[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
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
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 readers will
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 that
Valery Smyslov writes:
7. Page 31.
Phrase (see Section 2.6) actually references the same section. It should
either
be removed or corrected.
Changed:
tIn the first message of an initial IKE exchange, the
initiator will not know the responder's SPI value and will
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 in
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:
tA single CHILD_SA negotiation may result in
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 :-)
So
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
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
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 from
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,
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
is not
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
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
Michael Richardson writes:
Yoav Nir y...@checkpoint.com 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
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 of them
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.
Only
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
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 | RESERVED
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 it is
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 used
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
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 make
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 key
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 version that would be obsoleted by
draft-kivinen
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 expired
-lwig-ikev2-minimal-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Light-Weight Implementation Guidance
Working Group of the
IETF.
Title : Minimal IKEv2
Author(s) : Tero Kivinen
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
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 as
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
# Copyright (c) 2013 Tero Kivinen
# All Rights Reserved.
##
# Program: song-crack.pl
# $Source: $
# Author : $Author: kivinen $
#
# (C) Tero Kivinen 2013 kivi...@iki.fi
#
# Creation : 16
601 - 700 of 1088 matches
Mail list logo
