Grewal, Ken writes:
The 'bait and switch' attack where a connection uses ESP-NULL and
then at a later stage uses ESP-Encrypted may also be possible
unintentionally. E.g. Connection to a server (cluster / farm) to
gain access to a 'normal' service uses ESP-NULL and then at a later
stage, where
Grewal, Ken writes:
[Ken] This may be feasible for stateful devices, but does not work
for stateless devices (QOS/Statistics/auditing functions). Even in
stateful devices, it requires coupling between observation on flows
and the associated heuristics cache engine, which creates an
additional
Grewal, Ken writes:
Are QOS and auditing devices really stateless?
I would expect QOS devices to have all kind of reservation systems and
so on and for those I would expect them to be keeping state?
[Ken] QoS may be applied on the need of the underlying service. E.g.
A static rule that
Keith Welter writes:
RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying says:
The case where CHILD_SAs are being closed is even worse. Our
recommendation is that if a host receives a request to rekey the
IKE_SA when it has CHILD_SAs in half-closed state (currently being
pasi.ero...@nokia.com writes:
I have one somewhat substantial concern with the document: it needs to
be much clearer about what information is updated by the received
REDIRECT messages, and what is not.
Never really thought that issue. I myself assumed that both GWs are
identical, i.e. they
Vijay Devarapalli writes:
The draft currently requires the client to delete the SA once it
receives the REDIRECT message from the gateway. I do not want the
gateway to delete the SA right away. The gateway should allow the
client to setup the necessary security associations with the new
Yaron Sheffer writes:
I'm not sure in what way this is worse than other potential attacks at this
stage, such as sending back an unprotected notification saying that the
offered group is unacceptable.
If attacker sends notification back saying the offered group is
unacceptable, it will also
Yaron Sheffer writes:
From Appendix C: The specification does not say which messages can contain
N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is
not yet shown below.
SF discussion: Paul said, wherever you wish.
I agree on that. Logical places are:
1) In separate
Matthew Cini Sarreo writes:
I would like to ask the reason behind this. As live peer detection is done
by sending an empty INFORMATIONAL exchange (Encrypted Payload with no
payloads), wouldn't it better to have a response be constructed in such a
way so that the requesting peer can explicitly
Ticket #28 (new defect)
Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
Opened 7 months ago
Reported by: kivi...@iki.fi
Owned by: paul.hoff...@vpnc.org
Component:draft-ietf-ipsecme-ikev2bis
o Implementations MUST process received UDP-encapsulated
Yoav Nir writes:
The traffic selectors in the REKEY exchange are not currently
specified. If were designing IKEv2 from scratch, I would be in favor
of removing traffic selectors altogether from REKEY exchanges - I
don't think it should be called a rekey if you get a totally
different SA.
Matthew Cini Sarreo writes:
In such a scenario, it might be required to have different D-H groups for
different peers. Due to the ID payload being inexistant at this time, is
there a way (that is allowed) to identify a peer during IKE_SA_INIT (for
example, based on an IP address that has been
Paul Hoffman writes:
Greetings again. Tracker issue #98 is the same as the message that
Pasi sent to the mailing list last month; see
http://www.ietf.org/mail-archive/web/ipsec/current/msg04050.html.
There is disagreement among the authors of the session resumption
draft how to deal with this
J. Sun writes:
Matthew,
It has to be Case #2. No where in the CREATE_CHILD_SA - IKE_SA Rekey
exchange do you update to the other endpoint the new CHILD_SA SPIs -
without exchanging the CHILD_SA SPIs, you'll most definitely run into
interoperability issues, namely you'll start black
Paul Hoffman writes:
At 3:55 PM +0300 4/3/09, Tero Kivinen wrote:
Btw, is there any reason why [V+] is not listed in the IKE_AUTH
excghange with EAP in the intermediate EAP messages and final AUTH
request from the initiator?
We could add it, but I think that would surprise some implementers
Narayanan, Vidya writes:
Hi Yaron,
We are going back to revisiting consensus here and re-explaining the
use cases and I'd certainly like to keep this to as minimum a
revisit as possible. The use cases go back to what has been
documented in the problem statement we published a while back -
During the other discussion I read the
draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more
generic comments to it:
---
In Section 3 we present 2 use cases, and then after figure 1 start
talking about In this scenario... and I think that refers to first
use scenario described in
Kalyani Garigipati (kagarigi) writes:
Please validate if the following is true.
Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM,
TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE,
DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads.
Lakshminath Dondeti writes:
I still do not think making the 1 RT protocol to 2 RT protocol in that
case would really cause any noticeable effect to the actual handover.
How do you know this?
Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as
DHCP delays on WLAN
Matthew Cini Sarreo writes:
You still need the IDr and AUTH payloads in the reply. This is needed as
INVALID_SYNTAX is authenticated and encrypted.
INVALID_SYNTAX is fatal error meaning that other end didn't follow the
protocol specification, and the IKE SA is going to be removed anyways,
and
Lakshminath Dondeti writes:
When did MOBIKE come into picture? What are you saying Tero, that IPsec
session resumption is an alternative to MOBIKE and a slow one at that?
Yes.
Both solve the same problem that IKE SA recovers from the IP-address
change, or switching from one network to
Narayanan, Vidya writes:
Somehow, we in the IETF think that we can make decisions for other
standards bodies, especially ones that do real deployments. I don't
know how we can say things like they should always use the IKE SA
whether they need it or not - there can be several reasons not to
Lakshminath Dondeti writes:
You should not really do break-before-make style of transitions on
real-time environments, and if you keep the old connection while
making the new one, then this whole issue is non-issue.
Good advice, but that consensus process is from elsewhere. Not every
Paul Hoffman writes:
It was pointed out that (a) this is a new MUST and
Yes, but it can mostly be already deducted from the requirement that
end node cannot violate its own policy, meaning it needs to delete
Child SA which are not following his policy. If that is already done,
there is no point
Section 3 says:
The gateway MUST include the nonce data from the Ni payload sent by
the initiator in the REDIRECT payload. This prevents certain Denial-
but the figures showing how redirect is done does not include Ni data
in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it
Yaron Sheffer writes:
Patricia noted in a post to the IPsec mailing list (12/12/2008) that section
2.19 says that request for such a temporary address can be included in any
request to create a CHILD_SA (including the implicit request in message 3)
by including a CP payload.
IMO the normal
pasi.ero...@nokia.com writes:
Yaron Sheffer wrote:
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
some special handling. When a responder receives an IKE_SA_INIT
request, it has to determine whether the packet is retransmission
belonging to an existing 'half-open'
pasi.ero...@nokia.com writes:
Tero Kivinen wrote:
Paul Hoffman writes:
It was pointed out that (a) this is a new MUST and
Yes, but it can mostly be already deducted from the requirement that
end node cannot violate its own policy, meaning it needs to delete
Child SA which
Narayanan, Vidya writes:
The requirement is quite simple and you just seem to ignore it or
provide unacceptable alternatives. The handoff latency must be good
What handoff? We are talking about resumption, not handoff. I do not
consider those same.
Or then I understand completely wrong what
pasi.ero...@nokia.com writes:
(1) ask IANA to assign the four missing numbers (after IESG approval).
(2) submit an RFC Editor errata, saying something like this:
(3) ask IANA to include a pointer to this errata in the isakmp-registry
entries.
Does this sound like a reasonable plan?
I think
Grewal, Ken writes:
In the current traffic visibility draft, we indicate that WESP can be
negotiated via IKEv2 using a new protocol identifier.
Charlie Kaufman suggested that it may be plausible to use a notification
method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type of
Yaron Sheffer writes:
Yaron:
3.3.2: there is no explanation here or elsewhere that the D-H transform for
ESP and AH is used for PFS.
Paul (off list):
Not done. I don't think it belongs in 3.3.2, and I also don't agree that the
transform is the D-H transform for ESP and AH is used for
Yaron Sheffer writes:
3.5: this section is extremely liberal on what access control policies
people can implement, but that's too late to change now. However, we CAN at
least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945,
pki4ipsec).
...
The following new text, adapted
pasi.ero...@nokia.com writes:
What do you think of the proposed text here?
http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html
The NO_ADDITIONAL_SAS error should be added to the error list, and I
am not completely happy with the last paragraph, i.e. it could be
expanded bit more to
pasi.ero...@nokia.com writes:
Tero Kivinen wrote:
But now Bob cannot meet the requirement new SA MUST NOT be narrower
than the old one, because it would violate his policy.
This depends which happens first, algorithm selection or narrowing. In
most cases the first thing happens
Yaron Sheffer writes:
Hi Pasi,
Tero's mail gives a clearer explanation of the situation than your proposed
text. Gluing the two together, how about replacing your last paragraph with:
If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE_SA is not
Yaron Sheffer writes:
Hi Tero,
Sec. 3.3.2 mentions that you negotiate a D-H group for ESP/AH, even though
you only need encryption and integrity transforms for these protocols. I
find it confusing, certainly for newcomers. For clarity, I suggest to add
after the table in Sec. 3.3.3, this
Vijay Devarapalli writes:
In section 6 it should be:
(IP_R:500 - IP_I:500)
-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID,)}
Fixed all of the above.
(Again
pasi.ero...@nokia.com writes:
I agree that rekeying is currently not very easy to understand. But
e.g. early drafts of ikev2-clarifications (-00 and -01) included some
text wondering about what exactly N(REKEY_SA) means (that is, what is
different when you do/don't include REKEY_SA in
Michael Richardson writes:
Let me suggest a situation where perhaps I would like to bring up
an IKE_SA and not a CHILD_SA: it might be for just sending initial
contact, and perhaps even a DELETE.
I sometimes move quickly from being outside my IPsec gateway/firewall
(such as being on
Yoav Nir writes:
A far more common situation is when I'm outside, not moving
anywhere, and I want to connect. I haven't even opened my mail
client yet, or launched the browser (because those thing hate it
when the VPN client changes routing to addresses they are trying to
reach).
The
Yoav Nir writes:
I've submitted issue #107 about certificate encoding.
IMO it's not clear how certificate chains are to be encoded in IKEv2.
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107
If certificate chain is sent using X.509 certificate - signature (4)
format, then it is sent as
Paul Hoffman writes:
At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote:
Or possibly:
X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate
whose public key is used to validate the sender's AUTH payload. With this
encoding, if a chain of certificates needs to be sent,
gabriel montenegro writes:
Your point below about Next Header being useful is specially
valuable as it is from someone involved in developing these boxes.
If the box can do IPv6 header processing (which do require similar
offset calculations) to find the WESP header in the first place, then
gabriel montenegro writes:
Perhaps we need more details on what exactly we mean by the
endpoint thus must verify the sanity of the WESP header before accepting
the packet? And the action to drop the offending packet?
Yes. I think we need very specific rules with MUSTs in them to say
that
Yaron Sheffer writes:
I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP.
So yes, we use WESP for encrypted traffic to get:
- Extensibility (with the 8-bit Flags field).
This is future extensibility, which is needed only after we define
some future extensions using
Vijay Devarapalli writes:
Anyone else have any comments on including 4 - Locally Meaningful Name?
I can see use for that, so I would say it is good idea to add such.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
Paul Hoffman writes:
Title : Heuristics for Detecting ESP-NULL packets
S, that was two months ago, and there has been no discussion.
Has anyone other than the document authors (and the WESP authors)
read the document? Does the WG find this to be useful?
Tero and Dan:
Vijay Devarapalli writes:
7. Handling Redirect Loops
The client could end up getting redirected multiple times in a
sequence, either because of wrong configuration or a DoS attack. The
client could even end up in a loop with two or more gateways
redirecting the client to each
pasi.ero...@nokia.com writes:
- Section 5: Peer vendor IDs cannot be implementation specific -- if
the old gateway sent Vendor ID FOO, the client has to unambiguously
know whether it's allowed to FOO vendor-specific payloads to the new
gateway or not. Probably this should be Not resumed,
I read through this document, and it seems to be mostly ok.
Only think that might require clarification is the section 11. IANA
Considerations.
It currently says that A specification that extends this registry
MUST also mention which of the new values are valid in which
Notification payload.,
Sean Shen writes:
Hi, IPSECME WG,
The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The
modification addressed comments we received so far and also include some
other editing.
Major changes are as following:
#4
Section 3.2
Added clear reference to rfc4302 and rfc4307 for
Sean Shen writes:
The point here is to say that integrity protection is needed with aes-ctr,
not trying to specify which integrity algorithm to choose. rfc4306 already
required integrity for ikev2 and we refered to 4306 here. The choice of
integrity algorithm is up to rfc4307 or some update
Yaron Sheffer writes:
- Sec. 5. In the definition of IPsec flows, how is this done for (typically
tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow
definition? This text belongs either here or in Sec. 8.
Adding port numbers as part of the flow table might make some extra
Scott C Moonen writes:
Tero, I am not comfortable with the following statement:
. . . thus it will send back traffic selectors having IPN1 and IP2
as their IP addresses . . .
I would prefer that the server re-map the TS values back to IP1 and IPN2
when sending its response.
Yoav Nir writes:
Following is our suggested new text. Please let us know what you
think. Also, please take a look at the description of
AUTHENTICATION_FAILED in section 3.10.1. response to an IKE_AUTH
message means either an IKE_AUTH response to an IKE_AUTH request, or
an
naoyoshi ueda writes:
According to ikev2bis-04 section 2.1:
A retransmission from the initiator
MUST be bitwise identical to the original request. That is,
everything starting from the IKE Header (the IKE SA Initiator's SPI
onwards) must be bitwise identical; items before it
Yoav Nir writes:
Yes, altought I think most of the implementations do not bother
sending INFORMATIONAL requests when IKE_AUTH response has errors. I
think most implementations will then simply remove the IKE SA as
failed without any further communications to the other end
But wouldn't
David Wierbowski writes:
Tero, thanks for the comments and the clarification on how to read a lower
case must. I do have a few more comments.
So implementations cannot just search uppercase MUST/SHOULD/MAY
texts and assume it is enough to make sure those are correct. It also
needs to do
pasi.ero...@nokia.com writes:
If dpd is enabled then ikev2 counters keep updated frequently.
This depends on how often you do DPD... Obviously, you want dead
IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would
be sufficient for that. If your DPD interval was close to the
Keith Welter writes:
I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted
either.
I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be
deleted immediately after sending that response containing
INVALID_SYNTAX and if I receive INVALID_SYNTAX notification I will
Keith Welter writes:
In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr
payload in the
IKE_AUTH response which would would mean that creation of the CHILD SA
failed,
not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an
explicit delete
payload for
Yoav Nir writes:
OK. Let's try this again. Is this acceptable?
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic
Yoav Nir writes:
I wish that were true, but here's what the draft says about
INVALID_SYNTAX
INVALID_SYNTAX7
Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the
Yoav Nir writes:
I think MAY is better than SHOULD there, or even forbidding this
completely.
As said before I do not know any implementation which does this now,
and there is also problem that there is no way to correlate the
INFORMATIONAL exchange to the exchange which caused this
David Wierbowski writes:
You are sending an informational notification, so how could you say the SA
does not exist and no delete should be sent?
The IKE SA is NOT up and valid in the initiator. It is halfway up
as the other end has not been authenticated, and that IKE SA cannot be
used in
Scott C Moonen writes:
Tero,
Agreed. How about SHOULD, but adding if the error occurred in the
response to an IKE_AUTH exchange, and in payloads related to
authentication. A new exchange SHOULD NOT be triggered for reporting
errors in child SAs, CFG, or notifications.
If
Yoav Nir writes:
OK. One more try:
I think this is still bit confusing. How about splitting it to few
subsections, i.e.
2.21. Error Handling
2.21.1 Error Handling in IKE_SA_INIT
2.21.2 Error Handling in IKE_AUTH
2.21.3 Error Handling after IKE SA is Authenticated
2.21.4 Error Handling Outside
Yaron Sheffer writes:
- I would have liked to see ESP BEET mode referenced, since it's more widely
implemented than other docs that we do mention. But as far as I know it is
not on track to becoming an RFC.
I agree on that, and I think it might also be good to mention other
very widely
Paul Hoffman writes:
Greetings again. This message starts the WG Last Call on
draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and
comment on the list whether or not you think it is ready for
standardization. We are particularly interested in hearing from
implementers who have
pasi.ero...@nokia.com writes:
- A question: did the WG discuss the pros and cons of integrity
protecting the WESP header? (This does make WESP more complex to
implement, and currently the WESP header does not contain any data
that would benefit from integrity protection in any way.)
Thats is
David Wierbowski writes:
Thanks for the clarification. The text in 4301 makes sense. What I do not
agree with is the text in 4945 that requires implementations MUST be able
to perform matching based on a bitwise comparison of the entire DN in ID to
its entry in the SPD. I can agree with
Paul Hoffman writes:
At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote:
The ipsecme WG will have a virtual interim WG meeting in about a month. We
will have a conference call on Tuesday September 22, 15:00 GMT (18:00
Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on
Paul Hoffman writes:
Here is the edited text. Please be sure it is still correct.
There is the same typo my original text had:
tNAT A will then replace the source address of the IKE packet from
IP1 to IPN2, and NAT B will replace the destination address of the IKE
This should
Paul Hoffman writes:
#22 - Add section on simultaneous IKE SA rekey
There was no discussion. We will bring this up one more time
because it is important, but if there is not more interest and
more inclination to review Tero's text, we will write a short
note in the document
Paul Hoffman writes:
section anchor='sect-2.21' title='Error Handling'
tIf there is an error parsing or processing a response packet, the
general rule is to not send bac any error message because responses
^^^
s/bac/back/
should not generate new requests (and a
Paul Hoffman writes:
At 2:49 PM +0300 9/21/09, Tero Kivinen wrote:
The IP addresses are also needed for the RFC 3948 incremental checksum
fixup in udp encapsulation, not only for undoing the address
substitution.
As I said in my earlier note, I have removed all discussion of RFC
3948 from
Scott C Moonen writes:
tNOTE FOR WG DISCUSSION: Having other payloads in the message is
allowed but there are none suggested. One WG member mentioned the
possibility of adding a DELETE payload when the error is sent in a
separate INFORMATIONAL exchange. Do we want to allow such additional
Scott C Moonen writes:
- Is Section 1.2 necessary? None of these terms are used in this fashion
in this document.
True. Removed.
- page 8, sees an new = sees a new
- page 8, in the Section 8 = in Section 8
Fixed.
- page 12, excessive space in i.e. UDP encapsulated; perhaps replace
David Wierbowski writes:
I see no reason why Host A MUST NOT immediately delete the old IKE SA.
Deleting the IKE SA immediately makes it impossible to know what
happened to other exchanges going on the same IKE SA. Waiting for 30
seconds or so after rekey would allow those other exchanges to
Matthew Cini Sarreo writes:
Hello all,
I have a question regarding proper choosing of traffic selectors in the
situation where an initator is behind a NAT device. Let us use the following
scenario:
[initia...@a]--[nat@x][respon...@y]
Say A is 192.168.2.22, X is
David Wierbowski writes:
I agree with what you stated here, but I feel you are addressing something
that is not limited to a simultaneous rekey of the IKE SA. It deals with
any
rekey of an IKE SA. In my opinion the text is misplaced and should be in a
section that deals with handling of
Nicolas Williams writes:
- Section 7, 1st paragraph: MOBIKE is mentioned without a reference.
- Section 7, 2nd paragraph: s/avare/aware/
- Section 8.1, next to last sentence: this sentence is grammatically
incorrect, I think. How about:
If the protocol (also known as the, next
Shen Sean writes:
(3) Section 2 (and ff.)
...
The number of (internal) rounds is totally irrelevant for the
application of the AES. Any attempt to mangle with this 'parameter'
would raise significant security concerns and conformance issues.
I strongly request to elide all mention of rounds
David Wierbowski writes:
I'm not sure this makes RFC4718 incorrect. It just makes it incomplete.
Ok, but that still means we need to find a way to fix that problem
before we can use that solution in IKEv2bis.
This solution might cause peers to stay in live lock state, causing
the whole
Frankel, Sheila E. writes:
I interpreted RFC 4307 slightly differently than Tero does, and I
stand by the wording of both the USGv6 Profile and the IPsec
Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly
specifies both those algorithms used within IKEv2 and also those
Frankel, Sheila E. writes:
#115: Camellia req levels for IKEv2
Proposed changes to Roadmap doc:
1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC)
to optional
2) Add text to Section 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and Its
Use
Yaron Sheffer writes:
The definition of the payload (sec. 3.8) should mention explicitly
that the payload hash algorithm is unrelated to the one used in the
certificate, or the algorithm used to sign the IKE Encrypted
Payload.
What is the exact wording you are plannig to add there. As in some
Yaron Sheffer writes:
Sec. 3.7 has:
The contents of the Certification Authority field are defined only
for X.509 certificates, which are types 4, 10, 12, and 13. Other
values SHOULD NOT be used until standards-track specifications that
specify their use are published.
This is clearly wrong
Paul Hoffman writes:
At 9:58 AM +0300 10/30/09, Valery Smyslov wrote:
Hi all,
I'd like to reiterate my early message, which I haven't got answer to.
My concerns are:
1. How padding pre-sahred key with string Key Pad for IKEv2
could help to avoid storing pre-shared key in IKE
pasi.ero...@nokia.com writes:
I think you're correct that RFC 4307 has a bug: ENCR_NULL
should be MUST NOT, instead of MAY (note that ENCR_NULL
in 4305/4835 is MUST). Go ahead and submit an errata
about this!
Done.
--
kivi...@iki.fi
___
IPsec
Valery Smyslov writes:
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
Yoav Nir writes:
Since the gateway acts as a pass-through, the requirement here is
more for the client, which is typically more integrated. The client
should be prepared to give an identity hint both in IKE and later in
the EAP session.
And in that case the identities should really be same,
Jack Kohn writes:
From operational perspective if we are supporting both v4 and v6 (and we
will) then having different protocols ESP and AH is and will be a
nightmare. Common denominator is ESP-Null. However, there were issues with
ESP-Null as it couldnt be deep inspected which has now been
Nicolas Williams writes:
On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
Yes. That was what I tried to say. Do you think my already changed
sentence is ok, or do we need to explain it more.
Well, the heuristics will benefit from the information cached for the
TCP/UDP flow
Tero Mononen writes:
Overall comments:
The draft contains quite a lot of background information (what you are
trying to achieve on technical point of view, what were the
alternative solutions considered). Part of this background is also
available on WESP draft.
Making this
Submitted now a new version of the heuristics draft, which includes
changes from Williams, Mononen, Richardson, Graveman and Moononen.
This should now include all changes that were requested, if I missed
some, send me a note.
Draft can already be found from the ietf repository
Paul Hoffman writes:
We earlier agreed in issue #50 to make the KEr in Section 1.3.2
(Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
-- HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next one.
So, what
Paul Hoffman writes:
The 4th paragraph of section 3.3 says If an algorithm that combines
encryption and integrity protection is proposed, it MUST be proposed
as an encryption algorithm and an integrity protection algorithm
MUST NOT be proposed. This means that an integrity protection
Paul Hoffman writes:
This has flummoxed a few reviewers. Tables such as those in section
3.3.2 are already out of date because things have been added since
RFC 4306. I propose that we remove all these tables from IKEv2bis,
and add notes pointing to the current IANA registries. I cannot see
1 - 100 of 1088 matches
Mail list logo
