that the latter is right answer, but this probably must be written
excplicitly.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
. It is a bit unclear whether EAP generated key should also
be padded before use in IKE, or used directly.
Thanks,
Valery Smyslov.
- Original Message -
From: Valery Smyslov sva...@gmail.com
To: ipsec@ietf.org
Subject: [IPsec] Preshared key authentication in IKEv2
Hi all,
I found text
Hi Paul and Tero,
thank you for your answers.
The PRF (or set of PRFs) is known by the receiving party. If the two
parties always only use one PRF, it is known. The padding is not a
universal solution for the reasons you give, but it works in the
common case of peers who know each
Hi Paul,
please, see inline.
2. IANA registry already contains some very specific entries (like, for
example,
those that came from RFC4595) and their number will be increasing. I
think,
those numbers would confuse some implementers, who might be thinking
that they need to support all
For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I
think,
a newcomer could be confused by a long list of all possible numbers.
This answer is inconsistent, and that's the crux of the issue I have
You probably speaks about ideal developers. I speak about real people.
I've seen a few cases when people implemented a bunch of really
unnecessary things just because it was in standard.
We still agree, and your answer is still inconsistent. If you worry about
those type of developers, then
the are not
listed here again.
Regards,
Valery Smyslov.
I agree with Tero, regardless of the discussion we had on where to put the
tables etc., the document needs to be internally consistent. So we should
add the new notify types
it is better to rely on RFC4301 here and leave 3rd bullet out.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
key as one entity), and protocol specifications define rules for deriving
individual
keys from that child SA key (currently RFC4301 defines such rule for ESP and
AH).
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org
Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.
o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key
authentication.
Regards,
Valery Smyslov
and the initiator is authenticated using shared key
authentication.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
, that this will not make any existing product
non-conformant).
What others think?
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
in the diagram.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
at all, while having all public key authentication support for other
algorithms. Or implementation may elect not to support 1024 bits RSA keys
as not so strong. Do such implementations become non-conformant?
Is it possible to lower those requirements from MUST to SHOULD?
Regards,
Valery
be added? Otherwise it looks a bit
out of logic to me: either remove this paragraphs or treat IPv4 and IPv6 equally
and describe IPv6 implementation behaviour to the same extent.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https
) MUST be taken from
the first bits and the integrity key (if any) MUST be taken from
the remaining bits.
Looks fine to me.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
with the same
IKE SPIs and the Message ID and Exchange Type are copied from the
request. The Response bit is set to 1, and the version flags are set
in the normal fashion.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https
are not responses, (whichever WG will agree upon),
must be written down explicitely.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
any running code) or by rewriting text about
CHILD_SA_NOT_FOUND notification directing to put SPI
somewhere else apart from SPI field (probably to notification data).
Regards,
Valery Smyslov.
- Original Message -
From: Prashant Batra (prbatra) prba...@cisco.com
To: Valery Smyslov sva
Hi,
we've being running into this issue constantly. I think it is serious problem
for road warriers, who have to deal with all kinds of buggy or crippled SOHO
routers installed in hotels etc. Many our customers complain that they are
unable to connect to main office while being on business trip
Hi,
Hash-and-URL do require customer to deploy www-server. I admit that
for some enterprices that might be burden to deploy, but quite a lot
of other enterprices do already have working deployed www-server they
can use...
The url can be static, the certificate stored on that url can be
is irrespective to whether ESP-in-UDP employed or just plain ESP,
and is documented in RFC4301 section 8.
Regards,
Valery Smyslov.
Hi Valery,
There's something I'm missing here. Let's say we go for a solution where
we fragment IKE packets into pieces of 576 bytes, at the application level.
Now
Hi,
I submited an I-D describing a way to avoid IP fragmentation of large
IKE messages by fragmenting them on IKE level.
Comments are appreciated.
Regards,
Valery Smyslov.
-
A new version of I-D, draft-smyslov-ipsecme-ikev2
be done
(for example switch to another peer).
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Initiator and this port appears to be not reachable,
this Responder MUST NOT tear down IKE SA but MUST
instead fall back to UDP transport.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Hi Yoav,
Hi Valery
Thinking it over, I kind of regret adding the port field to the
TCP_SUPPORTED notification.
We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap
liveness checks
to keep the mapping in the NAT so that requests can be initiated to the
original initiator,
protocol
and makes it cumbersome.
Merry Christmas,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
leave it to some of the session resumption experts to comment on
point #1.
It's a little late for Merry Christmas, so just happy new year.
Yoav
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Valery Smyslov
Sent: Wednesday, December 26
Hi, Paul,
thank you for reading the draft.
I have a question about
http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00#section-2.5.1
It states:
2.5.1. Fragment size
When breaking content of Encrypted Payload down into parts sender
SHOULD chose size of those parts
attack.
And, of course, we have implemented this solution in our products.
And, of course, we are intersted in doing IKEv2 fragmentation
in standard, interoperable way (based either on our proposal or
smth else).
Regards,
Valery Smyslov.
--
kivi...@iki.fi
Hi Paul,
As for IKEv2, I don't know how Cisco is doing fragmentation in this case
(it seems to have support for it), but if it is done similarly to IKEv1,
than I prefer our own solution -
draft-smyslov-ipsecme-ikev2-fragmentation.
The main difference is that in Microsoft/Cisco solution (for
Our implementation also does not handle the first packet of an
exchange to be fragmented, because we have no state to store the
fragments for. In practise this does not matter because the first
packet is never large enough to need fragmentation.
We do the same.
So does it make sense to say in
- I would prefer the WG to stop working on IKEv2 over TCP and instead work
on standardizing IKEv2 fragmentation
I vote for this option.
Valery.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
There is no DH calculating per fragment. DH is calculated once in
IKE_SA_INIT
as in ordinary IKE SA establishment (note, that unprotected messages,
including IKE_SA_INIT
and IKE_SA_RESUME cannot be fragmented).
If we do IKEv2 fragments the way everyone does IKEv1 fragments, the
initiator
What your draft does, is force the initiator to protect each
fragment. To protect a fragment in a way that will cause the
responder to store it, requires running the MAC function, and that
in turn requires generating the keys (running the PRF), which in
turn requires completing the D-H
Hi,
I have posted a new version of IKEv2 Fragmentation draft.
It was rewritten to clarify protocol details and to accomodate
received comments.
Regards,
Valery Smyslov.
-
A new version of I-D, draft-smyslov-ipsecme-ikev2-fragmentation-01
,
Valery Smyslov.
The ipsecme working group is chartered to come up with a solution for
transporting long IKEv2 messages over networks that do not perform IP
fragmentation correctly, and as a result drop overly long messages,
usually IKE_AUTH messages.
We would like to invite the group
Hi,
I approved the conclusion.
Regards,
Valery.
- The group still thinks this is an important problem that needs an
interoperable solution.
- We would like to abandon the work on IKE-over-TCP.
- And to work on IKEv2 protocol-level fragmentation, using
still haven't see any
supporting comment from the WG. Yaron?
Probably we should get rid of (even completely optional) PMTU discovery at
all,
if it encouraged people to implement the protocol.
Regards,
Valery Smyslov.
A New Internet-Draft is available from the on-line Internet-Drafts
if the whole message could not be reassembled by
that time.
OK.
Regards,
Valery.
Thanks,
Yaron
On 2013-08-23 16:35, Valery Smyslov wrote:
Hi all,
I've just posted new version of IKEv2 Fragmentation draft.
Comments and reviews are appreciated.
Differences ftom -00 version:
1. As Yaron suggested
Hi Yoav, Yaron,
Sorry, I disagree. This notification is concerned with both old IKE SA (as
Child SAs sponsor) and
new IKE SA (as acceptor). So, to remain in concent with RFC5996 and to
be logically consistent,
I'd suggest to make SPI field empty (and Protocol ID zero) and to move SPI
for new
Hi Yoav,
What I could not find anywhere in the RFC is how to match name in the ID
payload to the certificate. In HTTPS we have a requirement that either the
CN or the dNSName alternate name match the domain name in the URL. We
don't have similar rules for IKE, do we?
Yes, we do: RFC4945.
So do you think it would be appropriate to mandate these matching
rules in rfc5996bis,
or should this be left to AD-VPN solutions. IOW, is such a standard
rule needed for generic IKE/IPsec?
It's definitely worth to mention these rules in RFC5996bis, or at least
point to the RFC4945.
And this not the only contradiction between RFC5996 and RFC4945 -
the latter requires ID_IPV*_ADDR to match source IP address of IKE
packet by default, while the former explicitely allows not to do it
in any case.
RFC4945 requires that implementations MUST be capable of verifying
the
Hi Raj,
IKEv2 fragmentation is mostly used for large sized packets. There are
use-cases when our
implementation needs to send huge sized packet over IKEv2 control plane
channel.
On lossy network if one of the fragment is lost, using current draft,
responder will not be able
to reassemble
Hi all,
I've just posted new version of IKEv2 Fragmentation draft.
Comparing with -02 version it clarifies Initiator's behaviour
with regard to retransmissions.
Regards,
Valery Smyslov.
- Original Message -
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Hi Yaron,
If Responder receives IKE Fragment Message after it received, successfully
verified and processed regular message with the same Message ID, it means
that response message didn't reach Initiator and it activated IKE
Fragmentation. If Fragment Number in Encrypted Fragment Payload in
I also think that PMTU discovery isn't very useful for IKE.
That's why it is MAY.
That does not help implementors who still have to implement the MAY's.
if even you as a document author does not think it is veru usefil,
then I think it should just not be in the document.
Sorry, I wasn't very
Hi Tero,
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
Hi Paul,
o Check message validity - in particular, check whether values of
Fragment Number and Total Fragments in Encrypted Fragment Payload
are valid. If not - message MUST be silently discarded.
should be changed to say:
o Check message validity - in particular, check
Sorry, I wasn't very clear. By isn't very useful I meant that it is
not useful
for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram
size that is not fragmented by IP level. In IKE its the goal is
different -
to find _some_reasonable_ IP datagram size that is not fragmented
Yes, sure. I'm planning to do it by Friday.
Could you wrap up the last set of suggestions for more text into a -04?
That would let us do a WG LC soon.
--Paul Hoffman=
___
IPsec mailing list
IPsec@ietf.org
. Rules for checking received fragment made more detailed.
4. PMTU described in its own section.
Regards,
Valery Smyslov.
- Original Message -
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Sent: Friday, October 18, 2013 4:32 PM
Subject: [IPsec] I-D Action
to make it suitable for progression to
Internet Standard.
Yes, your text is for RFC5996bis, while I made my notes a while ago
and the text was for RFC5996. Of course your variant is better.
Valery.
Thanks,
Yaron
On 2013-10-18 16:52, Valery Smyslov wrote:
Hi all,
as RFC5996 is revised, I
Hi Yoav,
Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does
IKEv1 fragmentation.
Actually, it is not a requirement in RFC1122, but only recommendation
(although a strong one):
Since nearly all networks in the Internet currently
support an
HI Yaron,
Hi Yoav,
You're probably right in your speculation. But my point was that Valery's
subject line said editorial changes, and two of these changes were
arguably non-editorial. Technical changes would be treated
Actually, I don't think #6 is technical, as It doesn't change
Hi,
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);
conversely, the Next
_any_reasonable_
MTU size that won't be fragmented by IP. Throughput is not important.
Third, PMTU discovery in the draft is completely optional and one may
use any other mechanisms (including PLMTUD, if it is available)
to obtain MTU information.
Thanks,
Valery Smyslov
field of the last contained payload
is set to zero).
has extra round bracket at the end.
Regards,
Valery Smyslov.
- Original Message -
From: Tero Kivinen kivi...@iki.fi
To: ipsec@ietf.org
Sent: Friday, October 18, 2013 4:15 PM
Subject: [IPsec] FWD from Cao Zhen \(CZ\): [Lwip] WGLC
This doc makes the case that IKEv2 should implement its own
frag/reassembly mechanism, because some NATs don't pass IP fragments.
First, the issue with NATs and fragments should be made more clear,
especially citing existing descriptions of this issue, e.g., RFC4787.
Note that NATs which do not
Hi Joe,
thank you for your suggestions. I still have some comments.
On 10/22/2013 11:25 PM, Valery Smyslov wrote:
I appreciate the work transport folks has done. I will also appreciate
if you point out what exact lessons should be applied here and why.
And you may consider PMTUD in IKE
That's true. I don't see any requirements in section 10.4. that the
probes
must be distinct. Request/reply nature of IKE's messages make them
well suitable for probes and I see no need here to introduce
separate mechanism, adding complexity, consuming bandwith and adding
delay.
Moreover,
Hi Raj,
1. As far as I understand, only one data channel can be created
within one IKE SA. So, if application needs several different
channels,
it have to create several separate IKE SAs, performing authentication
several times (probably involving human activity, if EAP is used).
Hi Tero,
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
Hi Johannes,
Your proposal creates exactly the issue which the draft is trying to
solve: The lack of flexibility by relying on IPsec
code points for the signature algorithm (as opposed to using existing OIDs
commonly used in certificates and CMS) and
the coupling of signing algorithms and
Hi Yoav,
thank you for your review.
I think the draft is in good shape and is almost ready for publication.
There is a bunch of grammatical issues with it, but I think the RFC editor
is much better at fixing those than most of us.
Section 2.5.1 recommends using 1280-byte max IP datagram size
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).
Except that if you continue to allow IP fragmentation, you can't claim
your solution is robust to IP fragment poisoning.
I think it is.
Consider the situation
Hi Matt,
the whole idea of the draft is avoiding IP fragmentation for IKE when
it prevents IKE to work. What about DF bit - I don't see how setting it
would help IKE to work.
Regards,
Valery.
- Original Message -
From: Matt Mathis
To: Valery Smyslov
Cc: tsvwg ; tsv
Consider the situation when IKE responder is under attack
via IP fragmentation (no matter which - poisoning attack or memory
exhausting attack). In any case responder will not be able to reply.
After some (short) timeout initiator will try to apply IKE Fragmentation.
Then, if those new messages
if IP fragments
exist
only on the part of the path, i.e. when fragmentation is done by intermediate
device.
- Original Message -
From: Matt Mathis
To: Valery Smyslov
Cc: tsvwg ; tsv-...@tools.ietf.org ; ipsec@ietf.org ;
draft-ietf-ipsecme-ikev2-fragmentat...@tools.ietf.org ; tsv
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 easy to fix.
We add
Hi Yoav,
Third version of this draft, now including Tero's comments.
some comments on new version.
First, some stuff seems to be left from previous version, which
supposed that new IKE SPIs are sent in both directions:
- third bullet in Section 2.2
- figure 2 in Section 3
Then, there is a
I think, that it could be solved, if we define new notification,
that could be optionally sent from gateway to client, informing him
that gateway is going to delete IKE SA in some time
interval (indicating that interval in the notification).
If cafr is supported by client and he is willing to use
We add suggestion to the draft that the responder should use same type
of key than what initiator used.
That will not work in case of EAP.
True, so in that case the Initiator needs to use proper CERTREQ or IDr
payload to indicate to which responder key he wants other end to pick.
We
clarified regarding probe timeouts.
4. More words about why PMTUD is done this way and not another,
its applicability and the situations when it may be useful.
4. More words in Security Consideration section about benefits
of avoiding IP Fragmentation in IKE.
Regards,
Valery Smyslov
Agreed.
Valery.
-Original Message-
From: Yaron Sheffer
Sent: Tuesday, November 12, 2013 10:18 AM
To: Tero Kivinen
Cc: Valery Smyslov ; ipsec@ietf.org
Subject: Re: RFC5996bis editorial change in section 1. Introduction (Was Re:
[IPsec] Editorial changes to RFC5996)
Looks good to me
Message -
From: internet-dra...@ietf.org
To: Valery Smyslov s...@elvis.ru; Valery Smyslov s...@elvis.ru
Sent: Tuesday, December 24, 2013 5:40 PM
Subject: New Version Notification for
draft-smyslov-ipsecme-ikev2-null-auth-00.txt
A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-00.txt
I think that using NULL Auth method clearly identifies
anonymous users and allows to distingush them from regular ones.
Adding special anonymous ID here seems to be superfluous.
Than you should stick to that and not send any IDs whatsoever.
If we mandate ID to always be empty in case of NULL
BTW, we have 3 possibility for inidicating anonymous ID.
1. Don't send ID Payload at all.
2. Send empty ID Payload (say, Type = 0, Len=0).
3. Send special ID Payload (say, Type=KeyId, Value=anonymous)
For me, case 3 looks the worst, I'd rather to avoid special values.
Case 1 looks the best from
think, well suited for these
purposes.
Regards,
Valery Smyslov.
- Original Message -
From: Yaron Sheffer yaronf.i...@gmail.com
To: ipsec ipsec@ietf.org
Sent: Tuesday, February 04, 2014 7:37 AM
Subject: [IPsec] Fwd: New Version Notification
fordraft-sheffer-autovpn-00.txt
Hi
that in this case you may gain even more economy
in power consumption than with current approach.
Regards,
Valery Smyslov.
- Original Message -
From: Yaron Sheffer yaronf.i...@gmail.com
To: Daniel Migault mglt.i...@gmail.com; Hannes Tschofenig
hannes.tschofe...@gmx.net
Cc: ipsec
.
And ESP-NULL with Auth is the only substitute there.
So, it must be MUST for any system.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Hi Daniel,
- Original Message -
From: Daniel Palomares
To: Valery Smyslov
Cc: IPsecme WG
Sent: Thursday, February 27, 2014 10:16 PM
Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition
Hello Valery,
Thanks for commenting on the draft .
Then, I've been
should either:
- remove explicit key length from AES-128-CBC and make it just AES-CBC
- add explicit key length to all other AES-based transforms (except for
AES-XCBC-MAC-96)
- leave things as is, but explain why AES-CBC differs in this respect from
the others
Regards,
Valery Smyslov
Hi Tero,
thanks for catching these typos and gramma errors.
Valery.
- Original Message -
From: Tero Kivinen kivi...@iki.fi
To: ipsec@ietf.org
Sent: Monday, March 03, 2014 8:25 PM
Subject: [IPsec] Comments to the draft-ietf-ipsecme-ikev2-fragmentation-05
I have read this document,
Thanks Yaron!
Valery.
- Original Message -
From: Yaron Sheffer yaronf.i...@gmail.com
To: Tero Kivinen kivi...@iki.fi; ipsec@ietf.org
Sent: Tuesday, March 04, 2014 12:49 AM
Subject: Re: [IPsec] Comments to
thedraft-ietf-ipsecme-ikev2-fragmentation-05
...And
HI Tero,
Hmm... actually we should most like use the same names we use in the
IANA registry.
Agree, this would make things more clear.
I think the best is to say that in general with AES encryption (GCM,
CBC, CCM etc) we assume the key length is 128-bits. (i.e. the
And don't forget
Hi Tero,
Anyways I think the document is in quite good shape, I think the
section 2.2 needs to be more specific about how to send the empty ID
payload. I think the idea of sending ID_IPV4_ADDR with 0 bytes of
data is very bad idea. The current text says you can omit data, and
that the type can
Hi Paul,
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 processed by particular
implementation, this may be inconvinient
But should you reject unauthenticated connections just because they
have ID which you are not authenticating anyways.
Yes I think so. You are changing the meaning of ID from implicitely
verified ID to potentially unverified ID. I think that is wrong.
But what prevent you from throwing away ID
o User wants to get some simple action from remote device. Consider
garage door opener: it must authenticate user to open the door,
but it is not necessary for the user to authenticate the door
opener. In this case one-way authentication is sufficient.
In this example there is no
But what prevent you from throwing away ID content in this case,
as you know that it is unauthenticated (you may even not to log it), and
allow user to connect? User has already exposed the
content of ID, the damage (if any) has already occured,
so what you will you protect by rejecting the
Hi Tero,
Thanks for reading and commenting the draft.
As I'm now a co-author of the draft, I'll try to answer.
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
Hi Paul,
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 me that,
is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions
Working Group of the IETF.
Title : IKEv2 Fragmentation
Author : Valery Smyslov
Filename: draft-ietf-ipsecme-ikev2
: Valery Smyslov
Filename: draft-ietf-ipsecme-ikev2-fragmentation-07.txt
Pages : 23
Date: 2014-04-04
Abstract:
This document describes the way to avoid IP fragmentation of large
IKEv2 messages. This allows IKEv2 messages to traverse network
devices that don't
practice for IKE extensions to be negotiated during IKE SA
establishment.
Regards,
Valery Smyslov.
Thanks.
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Sunday, May 04, 2014 12:56 PM
To: vijay kn
Cc: ipsec@ietf.org; vi...@wichorus.com; kilian.weni
outgoing SA deterministically and both peers use the same
SA, the other will eventually die by lifetime expiration
(as no traffic will flow through it).
Regards,
Valery Smyslov.
With Regards
Syed Ajim
-Original Message-
From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: 2014年5月4日 12:49
sections,
the overall language is improved (at least I hope).
Regards,
Valery Smyslov.
- Original Message -
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Sent: Friday, May 23, 2014 6:04 PM
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2
I've already asked co-chairs for a slot to present null-auth
in a private e-mail.
Valery.
On Tue, 3 Jun 2014, Yoav Nir wrote:
Well, there’s my puzzles draft ([1]).
There is also null-auth [2] which I think has not been presented. While
presenting it would be a one slide presentation, it
1 - 100 of 811 matches
Mail list logo
