This is the start of 2 week WGLC on the document, ending 2022-08-17.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
___
Robert Moskowitz writes:
> This latest ver is in response to comments recieved.
>
> Please review Appendix A that I have the RR properly set up.
I think the priority needs to be in decimal, and you are missing the
gateway address. I.e., at least the 4025 has examples as follows:
Paul Wouters writes:
> > The sequence number discussion mentions the issue of packets falling
> > out of the receive window. We talked about an IKE option/notify to
> > signal this and during that discussion it also came to light that this
> > protocol is going to be used
Only requests for agenda slots I have for next meeting are from Daniel
Migault about the new work, so current agenda looks like this:
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 114 - Monday July 25th, 2022
IPsecME WG will have its meeting on the Monday Session III (Monday,
July 25, 2022, 15:00-17:00 meeting time).
If you have any topics for the IPsecME WG Agenda, please send them to
me by the end of next week.
--
kivi...@iki.fi
___
IPsec mailing list
Tero Kivinen has requested publication of
draft-ietf-ipsecme-ikev2-multiple-ke-06 as Proposed Standard on behalf of the
IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke
黯乡魂 writes:
> Thank you for your reply. There is another issue about IKE SA rekey. After
> IKE SA rekey, a new SK_d is generated for the new IKE SA, so shall we update
> any existing child SA's key according to the new SK_d? I noticed that the
> child SA's key is derived from SK_d.
No. SK_d is
Tero Kivinen has requested publication of
draft-ietf-ipsecme-ikev1-algo-to-historic-06 as Proposed Standard on behalf of
the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic
Paul Wouters writes:
> > In the section 1 there is text saying:
> >
> > IKEv1 has been moved to Historic status.
> >
> > I think it is supposed to say "This document moves IKEv1 to Historic
> > status".
>
> We used the text because RFCs do not make documents Historic, it is IESG
> actions.
In the introduction there is text:
Algorithm implementation requirements and usage guidelines for IKEv2
[RFC8247] and ESP/AH [RFC8223] gives guidance to implementors but
limits that guidance to avoid broken or weak algorithms.
but the RFC8223 is completely unrelated to the matter in
In section 1.2 the text is describing the protocol in bit too much
historic point of view, it could benefit from more direct approach.
For example changing:
Some post-quantum key exchange payloads may have sizes larger than
the standard maximum transmission unit (MTU) size, and therefore
Valery Smyslov writes:
> I still think that it's better to put the text about resync into the
> Security considerations. I think this method is specific for Length
> corruption which most probably will happen as a result of injection
> attack. So, the new para in the Security considerations would
Valery Smyslov writes:
> Thinking a bit more about the problem:
> - IPsec stream consists mostly of random data (as result of
> encryption) with uniform distribution
> - if an attacker manages to overwrite a single Length field, then
> the beginning of the next packet (including the next Length
Valery Smyslov writes:
> Agree, that's what is in the suggested text:
>
>o if an attacker alters the content of the Length field that
> separates packets, then the receiver will incorrectly identify the
> margins of the following packets and will drop all of them or even
>
Valery Smyslov writes:
> If the TCP connection is abandoned (for any reason) and the
> associated IKE SA is still up, then the IKE initiator will re-create
> it. So, it is not a big deal, but definitely can influence
> performance. On the other hand, an attacker who is able to alter the
> packets
Valery Smyslov writes:
> > If you're the first expert to submit a review, please let us know
> > whether you want us to wait for both reviewers to respond before
> > we mark the document "IANA OK" (or send your comments to the
> > authors, if the registrations aren't OK).
>
> I don't think that
Valery Smyslov writes:
> Traditionally, IPsec specifications contain very few quantitatives
> concerning various timings. This is due to the belief that concrete
> timeouts don't affect interoperability. Instead, some very generic
> recommendations are usually given. See for example Section 2.4 of
ng
of the notification payload can be seen from the notify message type
field.
>
> ---------- Original --
> From: "Tero Kivinen" ;
> Date: Fri, Apr 22, 2022 03:55 PM
> To: "RFC Errata System";
> Cc: "黯乡魂"<648936...@q
RFC Errata System writes:
> The following errata report has been submitted for RFC7296,
> "Internet Key Exchange Protocol Version 2 (IKEv2)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6940
>
>
Robert Moskowitz writes:
> Yet in 8724, they define a in-band header:
>
> |--- Compressed Header ---|
>
> +-++
>
> | RuleID | Compression Residue | Payload |
>
>
I went through all reported errata, and here is my take on them.
It seems that if we mark errata as "verified" then it will get inline
fixes for the rfc by the rfc-editor, but if we mark it as hold for
document update we do not... I think most of those could also be hold
for document update, but
IPsecME will be meeting on Friday after the saag so I updated the
status on the datatracker to describe the current status
(https://datatracker.ietf.org/group/ipsecme/about/status/).
--
Intermediate draft is now approved by the
Here are my comments from the shepherd review.
In section 2.1 there is [TBD] for the TS Type of the TS_SECLABEL. As
we have already done the early allocation for the label, it would be
better to just fill it in.
Same for section 5 in IANA Considerations section, and there you can
also add note
Tero Kivinen has requested publication of draft-ietf-ipsecme-rfc8229bis-05 as
Proposed Standard on behalf of the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
___
IPsec
> Probably we can just reference RFC 4555.
>
> How about adding the following para
> (I also quotet here a part of a previous para, since I noticed that RFC 4555
> in fact
> doesn't contain normative language on these actions and thus we cannot use
> word "requires", more neutral tone is
Paul Wouters writes:
> On Tue, 22 Mar 2022, Tero Kivinen wrote:
>
> > So having few words here for mobike case would be useful too.
> > Especially pointing out that this is not specific to the TCP
> > encapsulation, this is generic thing that is done when using mobike
&g
Valery Smyslov writes:
> Changed to:
>
>If a NAT is detected due to the SHA-1 digests not matching the
>expected values, no change should be made for encapsulation of
>subsequent IKE or ESP packets, since TCP encapsulation inherently
>supports NAT traversal. However, for the
I was doing the review of the draft-ietf-ipsecme-rfc8229bis while
doing the shepherd writeup, and here are my comments to the draft.
In section 7.5:
--
If a NAT is detected due to the SHA-1 digests not matching the
expected
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 113 - Friday March 25th, 2022 11:30-13:30:00 UTC, 12:30-14:30 CET
https://meetings.conf.meetecho.com/ietf113/?group=ipsecme==1
Agenda
- Note Well, technical difficulties and agenda bashing -
Chairs (5 min)
- Document Status -
Chairs
Please send your presentation request for the IPsecME meeting for the
IETF 113 to ipsecme-cha...@ietf.org before the start of next week
(i.e., 2022-03-14), so I can make the agenda for the IPsecME meeting
then.
--
kivi...@iki.fi
___
IPsec mailing list
Valery Smyslov writes:
> After some thinking and recollecting I realized, that things are not that
> simple.
> It's true that SK_w is derived in QC-resistant way, but it is only used
> for providing confidentiality of the wrapped keys. Note, that their
> authenticity and integrity is provided only
Valery Smyslov writes:
> > The section 1.4.3/1.4.4 mostly already hints to that, but 1.4.1 is
> > more vague about it.
>
> We can make this more explicit by writing that
> GSA_AUTH is a variant of IKE_AUTH with different exchange type
> and slightly different properties and that G-IKEv2
Valery Smyslov writes:
> The latest text I proposed in reply to Paul's comments incorporates
> this strategy:
>
> o if the Responder chooses to send Cookie request (possibly along
> with Puzzle request), then the TCP connection that the IKE_SA_INIT
> request message was received
Benjamin Kaduk writes:
> I'd also like to confirm that the current (lack of) Updates:
> relationship between this document and RFC 7296 is correct. In §3.2, we
> reaffirm that the normal IKE rules for assigning Message IDs apply, so
> "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for
Valery Smyslov writes:
> The responder does use an existing TCP connection to reply, but once
> it replies with cookie request, it should close this connection. If
> it keeps this connection, then it keeps TCP state until the client
> resends IKE_SA_INIT request (if ever) and thus thwarts the idea
While reading the draft-ietf-ipsecme-g-ikev2-04 draft I started to
thinking whether we should get rid of the GSA_AUTH completely?
We have several extensions or enhancements that change the way
IKE_SA_INIT and IKE_AUTH are done, and porting those changes to the
GSA_AUTH is going to require extra
While doing IANA expert review on the document I found some issues
with this document, so here are my comments to it.
In section 5 there is text which says:
In particular, since AES-GCM is an AEAD
algorithm, ESP implementing AES-GCM MUST indicate the integrity
algorithm NONE.
We currently have two documents in the WGLC:
draft-ietf-ipsecme-g-ikev2: Group Key Management using IKEv2
and
draft-ietf-ipsecme-rfc8229bis: TCP Encapsulation of IKE and IPsec Packets
Both of those documents have very little reviews or comments during
the WGLC, and I would like to get at least
Tero Kivinen writes:
> This is the start of 2 week WG adoption call for this document, ending
> 2021-11-22. Please send your reply about whether you support adopting
> this document as WG document or not.
There was much less support for this, but I think there is enough
interest
Tero Kivinen writes:
> This is the start of 2 week WG adoption call for this document, ending
> 2021-11-22. Please send your reply about whether you support adopting
> this document as WG document or not.
We had some discussion on the mechanims defined in this draft, but
there was
Paul Wouters writes:
> So why not, instead of a random process, exchange the maximum Child SA
> lifetime accepted before rekey? If the numbers are identical, prefer the
> current exchange initiator.
>
> That way, it is deterministic and both endpoints inform the other end
> when (plus or minus
Don Fedyk writes:
> Thanks for spotting that, I posted replacements.
Thanks, submitted now to IESG for publication...
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Tero Kivinen has requested publication of draft-ietf-ipsecme-mib-iptfs-03 as
Proposed Standard on behalf of the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/
___
IPsec
Tero Kivinen has requested publication of draft-ietf-ipsecme-yang-iptfs-05 as
Proposed Standard on behalf of the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/
___
IPsec
Tero Kivinen has requested publication of draft-ietf-ipsecme-iptfs-12 as
Proposed Standard on behalf of the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/
___
IPsec mailing
For send-immiately there is text:
"On reception, end inner packets as soon as possible, do
not wait for lost or misordered outer packets.
Selecting this option reduces the inner (user) packet
delay but can amplify out-of-order delivery of
Christian Hopps writes:
> > Or if it is other way then add text saying "If this is true then inner
> > packets that are larger than what can be tranmitted in outer packets
> > will be dropped.".
>
> "Disable packet fragmentation across consecutive iptfs tunnel
> packets; inner packets larger than
Lou Berger writes:
> Hi Tero,
>
> You said:
>
> On 11/9/2021 5:11 AM, Tero Kivinen wrote:
> > I think there is still bit of tweaking that can be done,
>
> Is this tweak being made as a blocking comment by the document Shepherd
> or a non-blocking comment as
Don Fedyk writes:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03.txt
While answering the shepherd writeup question "Briefly describe the
review of this document that was perfmed by the Document Shepherd", I
had to read this document too, so here are some of my comments to
Valery Smyslov writes:
> So, the question to the WG is - what should we do with this:
>
> 1. Re-define calculation of IntAuth to make it constant in size.
> This will most probably require another WGLC and will break
> interoperablity of existing products. The latter seems not so
>
internet-dra...@ietf.org writes:
> Title : IP-TFS: Aggregation and Fragmentation Mode for ESP
> and its Use for IP Traffic Flow Security
> Filename: draft-ietf-ipsecme-iptfs-12.txt
I checked the diffs, and I think this text is mostly ok.
I think there is still
Paul Wouters writes:
> On Mon, 8 Nov 2021, Tero Kivinen wrote:
>
> >> Does the AuthMethod apply to the algorithms within the certificate
> >> as well? The RFC should clarify this.
> >
> > The reason for this notify is that if the peer has multiple key pai
Scott Fluhrer \(sfluhrer\) writes:
> I’m glad to see this work; however I see a potentially important
> constraint on authentication that the current draft does not appear
> to address.
>
> It allows the peers to specify which signature algorithms they
> accept; however if we are talking about
This is the start of 2 week WGLC on the draft-ietf-ipsecme-rfc8229bis
document, ending 2021-11-26.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
Here is IPsecME WG minutes. Thanks to minute takers, for making good
minutes and including enough of the discussion, especially for the
IPTFS issues.
--
IP Security Maintenance and Extensions (IPsecME) WG
IETF 112 - Monday
This is the start of 2 week WGLC on the draft-ietf-ipsecme-g-ikev2
document, ending 2021-11-26.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
This is the start of 2 week WG adoption call for this document, ending
2021-11-22. Please send your reply about whether you support adopting
this document as WG document or not.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
This is the start of 2 week WG adoption call for this document, ending
2021-11-22. Please send your reply about whether you support adopting
this document as WG document or not.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
Lou Berger writes:
> Hi Tero,
>
> see below
>
> On 11/5/2021 3:09 PM, Tero Kivinen wrote:
> > Lou Berger writes:
> >> I'd prefer to see the SHOULD and MAY reversed -- intentionally
> >> introducing additional reordering is generally considered somethin
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 112 - Monday November 8th, 2021 12:00-14:00 UTC
https://meetings.conf.meetecho.com/ietf112/?group=ipsecme==1
Agenda
- Note Well, technical difficulties and agenda bashing -
Chairs (5 min)
- Document Status -
Chairs (10 min)
- Work
Lou Berger writes:
> I'd prefer to see the SHOULD and MAY reversed -- intentionally
> introducing additional reordering is generally considered something to
> avoid.
Yes, intentionally introducing reordering or delay SHOULD be avoided,
thats why it is important to keep the SHOULD and MAY as
We will be meeting on Monday November 8th 12:00-14:00 UTC, so send me
agenda request as soon as possible so we get the agenda ready soon.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Christian Hopps writes:
> Will you be able to provide the text changes that would cover the
> issue you have? Would really like to get this submitted to IESG
> before another IETF cycle completes.
How about following:
--
2.5.
Daniel Herzinger writes:
> the fact is that accepting a significantly increased amount of data
> from an unauthenticated peer also significantly increases the
> surface to DoS attacks.
Accepting data is not a DoS attack problem.
If the other end sends you lots of packets, you will have to cope
Daniel Herzinger writes:
> in response to the new version of
> draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize
> the issue of DoS attacks during intermediate exchanges. The new
> version does address it by mentioning the option of simply avoiding
> intermediate exchanges
Christian Hopps writes:
> >> I believe this is a good change, and addresses Tero's concern about
> >> long delays if a timer is not used.
> >
> > No it does only notes there is an issue, and proposes a partial
> > solution to it, but still does not really address it.
> >
> > I still do not
Christian Hopps writes:
>
> Christian Hopps writes:
> >
> > I'm saying we should add new text that mentions the use of this
> > drop timer to drop missing packets after a short waiting time
> > instead of just waiting for it to slide out of the reorder window.
> > Then there is no issue to
Christian Hopps writes:
> I also need to point out that we are only talking about the case
> where the implementation doesn’t use a timer to timeout missing
> packets. We specifically added text highlighting that
> implementations are free to timeout missing packets much earlier if
> they so
Christian Hopps writes:
> In particular why don’t we simply indicate that a lost packet can
> induce a delay of the fixed packet interval times the window size -
> 1, and so the widow size should be kept to a minimum, and leave it
> at that.
As the window size is configured by the adminstrator
Christian Hopps writes:
> Let’s keep things simple here at this point in the process, and also
> match the results we have already verified with running code.
In real production use over internet or in the lab between two test
machines (or inside one datacenter between machines there)?
> We can
Christian Hopps writes:
> >> It might be obvious to you, but it might not be obvious to the person
> >> doing the actual implementations. I always consider it a good idea to
> >> point out pitfalls and cases where implementor should be vary to the
> >> implementor and not to assume that
Christian Hopps writes:
> We certainly did not want to specify whether an implementation
> SHOULD forward complete inner packets, out of order, or not, b/c
> that is not required for interoperability.
My reading is that current text says you MUST NOT forward complete
inner packets until all
This is the start of 2 week WGLC on the draft-ietf-ipsecme-mib-iptfs
document, ending 2021-08-31.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
This is the start of 2 week WGLC on the draft-ietf-ipsecme-yang-iptfs
document, ending 2021-08-31.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
Tero Kivinen writes:
> This is the start of 2 week WGLC on the
> draft-ietf-ipsecme-ikev2-multiple-ke document, ending 2021-08-10.
>
> Please submit your comments to the list, also send a note if you have
> reviewed the document, so we can see how many people are interested in
>
There was no issues raised during the WGLC, so this document we will
be starting the publication process of this draft soon.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
I checked the WGLC email threads on the list, and I think consensus
was to move this draft forward, but there were some issues pointed up
during the last call that still do require to be addressed before
that.
I moved this draft now to WG Consensus: Waiting for Write-Up: Proposed
Standard state
Christian Hopps writes:
> During the last IETF meeting it was agreed that we would move
> quickly to resolve any issues that Tero had left, and get this
> document submitted to the IESG. So asking again if the new version
> (published prior to the meeting) satisfied the issues so we can move
>
Valery Smyslov writes:
> Hi Tero,
>
> > I was reading the draft-ietf-ipsecme-ikev2-intermediate through and I
> > think it might be good thing to add a note at the end of section 3.3.1
> > Protection of the IKE_INTERMEDIATE messages to clarify which SK_e[i/r]
> > and SK_a[i/r] are to be used for
I was reading the draft-ietf-ipsecme-ikev2-intermediate through and I
think it might be good thing to add a note at the end of section 3.3.1
Protection of the IKE_INTERMEDIATE messages to clarify which SK_e[i/r]
and SK_a[i/r] are to be used for the IKE_AUTH after all
IKE_INTERMEDIATE exchanges (I
This is the start of 2 week WGLC on the
draft-ietf-ipsecme-ikev2-multiple-ke document, ending 2021-08-10.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
This is the start of 2 week WGLC on the
draft-ietf-ipsecme-labeled-ipsec document, ending 2021-08-10.
Please submit your comments to the list, also send a note if you have
reviewed the document, so we can see how many people are interested in
getting this out.
--
kivi...@iki.fi
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 111 - Monday July 26th, 2021 21:30-22:30 UTC
https://meetings.conf.meetecho.com/ietf111/?group=ipsecme==1
Agenda
- Note Well, technical difficulties and agenda bashing -
Chairs (5 min)
- Document Status -
Chairs (5 min)
- Work items
As we now do have one hour meeting in the next IETF, I would like to
ask people to send agenda requests to me as soon as possible. We only
have one hour, so we might need to limit number of items on the
agenda, so thats why I want to have list of agenda items early.
So send your agenda requests
Christian Hopps writes:
> > On Jun 27, 2021, at 10:30 AM, Paul Wouters wrote:
> >> On Jun 27, 2021, at 05:04, Christian Hopps wrote:
> >> I don’t see ipsecme scheduled at IETF 111, is there no meeting?
I was too busy before my vacation and forgot to do it before I left
sailing.
> > I hope
Dan Harkins writes:
> >> - there is another IKEv1 feature not available in IKEv2: a deniable
> >> authentication method. IKEv1 had a very cool deniable exchange
> >> involving encrypted nonces. IKEv2 decided to not support that for
> >> whatever reason. Lack of support for a cool and
Christian Hopps writes:
> The replay window does not need to be the same size as the reorder
> window.
But effectively it is same as there is no use of having them
different.
If my reorder window is set to 2, and my replay window is set to 1000,
if there is any reorderining happening then even
Christian Hopps writes:
>
> For very slow tunnels such as your indicating, you are not worried
> about out-of-order delivery; just set the reorder window to 0.
We do care about the replays even when we do not care about reorder,
so setting reorder window to 0 is not acceptable, as that would
Christian Hopps writes:
> I'm not sure what you mean by Huge delays. Given an example of a 10
> kilobit tunnel
10 kilobytes not kilobits, i.e. about 80 kilobits/s. This can handle
several low quality audio connections inside, or one high quality
uncompressed cd-quality mono channel.
> (really?)
While reviewing the draft for publication I found out that section 2.5
says that we first reorder packets, then make sure we have not missed
any packets, and only after that we process the in-order payload
streams to extract the inner-packets.
The problem is that packet is considered lost only
I now closed the WG adoption call and marked this document as adopted
by WG. There were some comments requested during adoption call, and I
would hope authors would process those and submit next version of the
draft as WG document.
When I was myself checking the document I noticed that it referes
Bottorff, Paul writes:
> The RFC3948 specifies one pair of UDP ports 4500-4500.
No it does not. It says you must use same ports than what you do for
IKE traffic.
> Both the IKE flow and the ESP in UDP flow should use the same UDP
> flow. The draft seems to suggest new destination port and source
Paul Wouters writes:
> Reading back now, I think with some clarifications added, I am okay
> with the document. I think the list of clarifications we now have is:
I think your list of things to add is mostly ok.
Note, that on some enviroments creating random numbers is possible,
but it takes
Paul Wouters writes:
> On Sun, 21 Mar 2021, Daniel Migault wrote:
>
> (replying to some issues here, but also added a full review of the document)
>
> Side note: I am bit confused why this document would not be a document
> from the IPsecME WG ? I know we talked about this before? Did we decide
Valery Smyslov writes:
> the 1.5 week period is over and nobody objected the adoption.
> Is there any reason the draft is not WG document yet?
Nope. Done.
I still have the WGLC calls for labeled ikev2 and multiple-ke drafts
in my todo list, but those will take few days, as I want to read the
This is the start of 2 week WG adoption call for this document ending
2021-03-22. Please send your reply about whether you support adopting
this document as WG document to this list.
This is part of the Traffic Flow Confidentiality work in the charter.
--
kivi...@iki.fi
This is the start of 2 week WG adoption call for this document ending
2021-03-22. Please send your reply about whether you support adopting
this document as WG document to this list.
This work is considered as maintenance of the IPsec, thus is covered
by the generic maintenance work.
--
Paul Wouters writes:
> On Tue, 2 Mar 2021, Tero Kivinen wrote:
>
> > - New items
>
> Can we talk 5 minutes about
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt as well ?
>
> The IPR issues are resolved, and I think it is a useful document to
> imp
Here is the IPsecME Agenda for IETF 110 meeting. Please submit your
slides before the Friday this week.
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 110 - Monday March 8th, 2021
Agenda
- Note Well, technical
Valery Smyslov writes:
> so, what is the outcome? Do you think we should add a recommendation
> not to include source IP address in cookie calculation when TCP is in use?
I am not sure. Perhaps just add comment, that when using TCP the outer
IP address of the NAT might change more often than in
101 - 200 of 1088 matches
Mail list logo
