Talking as IANA expert, I am planning to send following email to iana.
We did discuss this in the Bangkok IETF, and as an IANA export for the
IKEv2 registries think this is much better idea, than to copy the
recommendations from the RFC8221 an RFC8247 to the iana registry.
Does anybody have any co
Paul Wouters writes:
>
> Recently we had a discussion about mapping IANA entries to a yang model,
> and the question came up whether we sould add a deprecated marker to the
> IKE/ESP registries for algorithms.
>
> I thought it was a good idea, but not everyone agreed.
>
> I just stumbled upon RF
mohamed.boucad...@orange.com writes:
> > We have following cases:
> >
> > 1) Initiator only supports/wants one address family, and it requests
> > it. If responder supports that address family it will give address
> > from that address family.
>
> [Med] Yes.
>
> If it also supports another fami
Paul Wouters writes:
> On Tue, 29 Jan 2019, Tero Kivinen wrote:
>
> > In "Transform Type 2 - Pseudorandom Function Transform IDs" of
> > "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as
> > follows:
> >
> > To find out re
Paul Wouters writes:
> > Or we can change the reference column for those to point to
> > RFC8221/RFC8247 for those where they say it is MUST NOT.
> > That is something that is easy to do with just sending request to
> > iana.
>
> Either works, that was what we were trying to do :)
Ok, then I misu
mohamed.boucad...@orange.com writes:
> > > [Med] This is more complicated compared to the current design in the
> > > draft which allows to return a status code. The initiator will then
> > > know whether it has to retry with another address family.
> >
> > I do no see any difference here.
>
> [M
Paul Wouters writes:
> On Wed, 30 Jan 2019, Tero Kivinen wrote:
>
> >> Either works, that was what we were trying to do :)
> >
> > Ok, then I misunderstood what people were saying earlier, I understood
> > some people wanted to have similar new column that TLS had
Paul Wouters writes:
> 5.1.3. X.509 Certificate Extensions
>
> Conforming IKE implementations MUST recognize extensions that must or
> may be marked critical according to this specification. These
> extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
>
> [...]
>
> W
Paul Wouters writes:
> On Wed, 30 Jan 2019, Tero Kivinen wrote:
>
> > No. Only change the reference to the document that says those
> > algorithms are MUST NOT. You wanted clickable link to document that
> > will tell the status. This results in what you asked for
&g
This document has been stable for some time, and I think it is ready
to go forward. Because of that I will start one week long WG
adoptation call for this draft which will expire end of next week
(2019-03-22).
If you have any reasons why this should not be adopted as WG document,
send email to the
I am now setting up the agenda for IETF 104, so if you have any
presentation etc you want to present there (and I have not yet sent
email to you about it), send requests to us chairs
as soon as possible (i.e., before the end of
THIS week i.e., before 2019-03-15).
--
kivi...@iki.fi
__
We seem to have full agenda for IETF 104 in Prague.
I want all who are going to present in the meeting to provide slides
before Friday next week (2019-03-22 23:59 UTC). If we do not have have
slides then, then we might have more time on agenda, as we can remove
some presentations :-)
Tero Kivinen writes:
> We seem to have full agenda for IETF 104 in Prague.
And I had forgotten one presentation from the list (hybrid-qske), so
now our agenda has too many items. We will be talking to presenters so
which ones will be shortened or skipped.
> I want all who are going to pres
Document Status:
- draft-ietf-ipsecme-split-dns (David)
In RFC editor queue.
- draft-ietf-ipsecme-qr-ikev2, Quantum Resistance (David)
Ready for publication. Waiting for revised version.
- draft-mglt-ipsecme-implicit-iv (Tero)
Publication requested.
- draft-ietf-ipsecme-ipv6-ipv4-codes
Here is the preliminary minutes for the todays IPsecME meeting. Thank
you for Yoav for taking the notes, and Paul for jabber scribing.
If you have any comments, corrections or additions to minutes, post
them as soon as possible. I will submit these to the meeting materials
early next week.
---
Valery Smyslov writes:
> > One additional question came to my mind on whether we update the
> > RFC mentioned above or not. We could consider our document as an
> > alternate mechanism to generate the IV of the existing RFC.
>
> No, since you define your own transforms (with own code points) you
>
In the Prague meeting we had two options how to send information what
kind of address families are supported [1]:
1) IP6_ONLY_ALLOWED and IP4_ONLY_ALLOWED status notifications which
are sent whenever only one address family is supported. I.e., if
only one address family is supported, then IP
Paul Wouters writes:
> > [Authors] We have observed some implementations (e.g. libreswan)
> > has this variable initial-contact as well in the ipsec.conf. That is
> > why we decide to
> > keep it. Is it not useful then?
>
> We added it because sending or not sending it might change te behaviour
>
Rafa Marin-Lopez writes:
> Hi Tero, Paul:
>
> El 2 jun 2019, a las 17:09, Paul Wouters escribió:
>
> On Sun, 2 Jun 2019, Tero Kivinen wrote:
>
> I.e., if you have separate connections that share same authenticated
> identity then you need to
Paul Wouters writes:
> NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec
> proposal list matches due to all proposals having at least one mismatching
> transform" versus "no matching ike connection for your IKE proposal"
> where proposal refers to the entire IKE proposal, not
Now, when I am back from my Chile eclipse trip, I have some time to
start working on the IETF issues again.
So please send requests for agenda items for Monteral IETF to the
chairs as soon as possible. We already have following requests for the
agenda, and I would like to finalize the agenda quite
for approval) as soon as
possible.
--
# IPsecME WG
## IETF 105, Montreal
* Date: 2019-07-23
* Time: 15:20-16:50 (90 min)
* Room: Sainte-Catherine
* Chair: Tero Kivinen
* Chair: David Waltermire
---
## Agenda
Rafa Marin-Lopez writes:
> We submitted a new version of the I-D (v05) where we have applied several
> changes. In the following you have a summary of the main changes, which we
> will expand/explain during our presentation:
I put that on my to-read queue. Cannot promise when I have time
to read
)
* Room: Sainte-Catherine
* Chair: Tero Kivinen
* Chair: David Waltermire
---
## Agenda
### Adminstrivia (5 min)
* Agenda bashing, Logistics -- Chairs (5 min)
1) Paul asks about Graveyard draft, Chairs mention that authors need
to push, chairs won't pull.
Paul says that it is read
[removed cfrg from CC, as I do not think this issue really belongs
there as we are discussing IKE signaling here].
Dan Harkins writes:
> First of all this suggestion is for a particular PAKE and I'm not
> suggesting that any of the other candidates would slide in so effortlessly.
> In fact an au
Dan Harkins writes:
> > How does the responder know which of the one million username password
> > pairs to pick to generate the generator when calculating D-H in the
> > IKE_SA_INIT? The actual identity of the user is only sent in the
> > encrypted IKE_AUTH message.
> >
> > I.e., I think this has
Tristan Ninet writes:
> Dear Mr. Wouters,
>
> Thank you for your interest in our work.
>
> > I've read through the paper, and I believe is very much misrepresents what
> > it
> > deems is a DoS attack against the IKEv2 protocol.
> >
> > The DoS attack described seems to think it can change the I
So this is fast (one week) adoption call for the
draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We
did have quite positive feedback in last IETF meeting and the charter
item is being worked on in parallel to this call.
If you support adopting this document as WG document and as
If you have some agenda slots or presentations you want to make in the
IETF 106 IPsecME WG meeting in Singapore send email to
ipsecme-cha...@ietf.org to request a slot.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman
This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2
draft to be accepted to be WG Document. This draft has been around for
some time, and we have been discussing it in the meetings.
If you support adopting this document as WG Document, then send email
indicating your support to the
This is a adoption call for the draft-yeung-g-ikev2 draft to be WG
document. This document has been around for long time, and we
inherited it from the msec WG when it closed down. We have already
decided to take this as an chater item so making this WG document
should be ok.
If you support adoptin
ole thing trying to verify whether it is hardware or software
issues, and this operation took several days instead of few hours it
was supposed to do...
> Thanks,
> Chris.
>
> > On Oct 26, 2019, at 11:17 AM, Tero Kivinen wrote:
> >
> > So this is fast (one week) a
Paul Wouters writes:
> On Wed, 6 Nov 2019, Valery Smyslov wrote:
>
> > Do you think the current diagrams are confusing?
>
> Yes. Because often I go back to RFCs and only look at the diagrams
> expecting it to be what I need to implement. So for optional/required
> payloads, I would mostly look at
Benjamin Kaduk writes:
> Section 3
>
>N(USE_PPK) is a status notification payload with the type 16435; it
>has a protocol ID of 0, no SPI and no notification data associated
>with it.
>
> [check the IANA status of the value]
As others already commented I as an IANA Expert for those r
min)
* Room: Olivia
* Chair: Tero Kivinen
* Chair: David Waltermire
---
## Agenda
### Adminstrivia (5 min)
* Agenda bashing, Logistics -- Chairs (5 min)
### Draft status -- Chairs (10 min)
* draft-ietf-ipsecme-implicit-iv
- Implicit IV for Counter-based Ciphers in Encapsulating
:50-17:20 (90 min)
Room: Olivia
Chairs: Tero Kivinen , David Waltermire
Scribe: Sean Turner
Agenda
==
* Adminstrivia (5 min)
* Agenda bashing, Logistics -- Chairs (5 min)
* Draft status -- Chairs (10 min)
* Work Items (25 min)
* draft-tjhai-ipsecme-hybrid-qske-ikev2 Interop
Benjamin Kaduk writes:
> It looks like the "reference" column for the registry dind't make it into
> the -09, but I'm happy to include that change along with the last-call
> feedback.
If you are talking about the reference column of the IANA registries,
then they are not needed in the draft (or rf
Valery Smyslov writes:
> I don't think option 4 is a good idea. If old responder
> encounters an unknown payload with Critical bit set in IKE_AUTH, it will
> return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up.
> See section 2.21.2 of RFC7296. This would require initiator to retry
Benjamin Kaduk writes:
> On Thu, Dec 12, 2019 at 10:38:41PM +0200, Tero Kivinen wrote:
> > Benjamin Kaduk writes:
> > > It looks like the "reference" column for the registry dind't make it into
> > > the -09, but I'm happy to include that change along
Valery Smyslov writes:
> In our case the strategy for initiator is: retransmit and wait.
> If even after several retransmission it doesn't receive message
> with SECLABELS_SUPPORTED, then there is no reason to continue
> with IKE_AUTH (if using labels is mandatory for initiator).
> If it receives a
Éric Vyncke via Datatracker writes:
> --
> COMMENT:
> --
>
> Thank you for the work put into this document. I found it very
> interesting to read BTW. I have only
Benjamin Kaduk writes:
> I see in
> https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00
> that we didn't want to get rid of 3DES at that time. Do we have a sense
> for how quickly that will change, the scope of existing deployments, etc.?
One of the problems is that we as an
Benjamin Kaduk writes:
> Sorry! I think that the current charter allows us to do an 8229bis
> without additional rechartering.
Good.
I myself think it is better to do bis documents than just
clarification guidelines as splitting things to multiple documents do
make things harder to implement.
Al
Paul Wouters writes:
>
> Recently I had an interesting issue come up. I needed to generate a
> certificate with a specific OU= content that our openssl/python
> code couldn't do, and I switched to nss's cert-util to generate
> a cert of sets for a test.
>
> Then I noticed something strange. Let's
Christian Hopps writes:
> Dear ipsecme Chairs,
>
> This request is inline with the guidelines as set forth in RFC7120
> (https://tools.ietf.org/html/rfc7120)
>
> I would like to request early allocation of the IP protocol number
> [A] used for the ESP payload identifier for IPTFS (suggested valu
[talking as individual and one of RFC7296 authors, not as WG chair].
Toerless Eckert writes:
> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
> > The RFC states:
> >
> >The USE_TRANSPORT_MODE notification MAY be included in a request
> >message that also includes an SA payl
Michael Richardson writes:
> Unless we can convince various people otherwise, the TA will all be
> private enterprise/ISP CAs.
And for some reason those same private enterprise/ISP people are
exactly those who say that we can't leak our CA certificates out, and
thats why we can't have publicly ava
Valery Smyslov writes:
> > I think examples of where DN would not be sufficient (and its in the -25
> > text) would be expired certs from the correct CA, or certs from
> > a misconfigured registrar with CA - where the operator unintentionally
> > re-created a CA with the same DN, instead of going t
'Toerless Eckert' writes:
> > And for some reason those same private enterprise/ISP people are
> > exactly those who say that we can't leak our CA certificates out, and
> > thats why we can't have publicly available repository of our
> > certificates or CAs, which of course lead to problem if you m
'Toerless Eckert' writes:
> > If you ever need to talk to devices that are not part of same
> > authorization domain you need that feature (unless you want to
> > provide lots of manual configuration to IKE).
> >
> > I.e., if you connect to SGW1, you need to use public/private key pair
> > and ce
Michael Richardson writes:
> I am not really following this discussion very well.
> I'm not sure if this is general advice or ACP specific advince.
This discussion was not ACP specific, this was just generic reasons
why CERTREQ etc are usuful in general. Anyways I think most ACP cases
do not need
Here is preliminary minues from the IETF 108 IPsecME WG meeting. I
copied some discussion about the proposed changes to ESP from Jabber
to here, as I think it was important to record those even when we did
not have time to have comments during the meeting.
If you have any comments, please send th
This has also been stored in the datatracker as status update for the
IPsecME WG (https://datatracker.ietf.org/group/ipsecme/about/status/).
--
Implicit IV was published as RFC8750, and Mixing Preshared Keys in
the IKEv2 for Post
Scott Fluhrer \(sfluhrer\) writes:
> As for the idea of moving the integrity check value before the
> encapsulated packet, well, that idea might help on your platform;
> however it strikes me that the advantage would likely be fairly
> platform dependent.
Yes. In several kernel implementations the
Steffen Klassert writes:
> We have already the option to send the high sequence number bits
> when a combined mode algorithm is used.
>
> RFC 4303, Section 2.2.1. says:
>
> If a combined mode algorithm is employed, the algorithm choice determines
> whether the high-order ESN bits are transmitted
Michael Rossberg writes:
> Like pointed out in the answer to Valery’s mail. There are possibly more
> issues, as attackers are able to generate new traffic, they can use for
> cryptanalysis (see
> https://www.aircrack-ng.org/doku.php?id=arp-request_reinjection).
If any of our algorithms are vulner
Scott Fluhrer \(sfluhrer\) writes:
> No, RFC4106 (June 2005) predated 800-38D (November 2007) by over two years.
Ah, didn't check the dates, and the NIST document didn't really
explain the reason behind it, it just said you preferrably need to
have 32-bit fixed part.
> Instead, it was inserted to
William Allen Simpson writes:
> > So it might make sense to have the ICV at the end because it is
> > likely cache hot when needed.
>
> But after removing padding for these stream algorithms, then the ICV is
> very likely not aligned. For zero-copy RDMA, it is rather inconvenient.
> And the IP he
Michael Richardson writes:
> > We added a suspend commend, but since that deleted states on the
> > initiator, it ended up sending delete's to the server. The server
> > deleted the IKE SAs. Now the client can resume a connection that
> > technically was ended by Delete.
>
> It see
Paul Wouters writes:
> On Fri, 28 Aug 2020, Michael Richardson wrote:
>
> >> We added a suspend commend, but since that deleted states on the
> >> initiator, it ended up sending delete's to the server. The server
> >> deleted the IKE SAs. Now the client can resume a connection that
> >
Paul Wouters writes:
> On Mon, 31 Aug 2020, Tero Kivinen wrote:
>
> > That should not matter, the server should not invalidate tickets even
> > if there is liveness failures, as if it does that every time there is
> > transient network failure the resumption is useless.
&
Michael Richardson writes:
>
> Tero Kivinen wrote:
> > Normally the ticket is encrypted with key that is changed every time
> > the server configuration changes, which means changing the server
> > configuration will invalidate all tickets.
>
> This
By first look the changes seemed way too big for errata, but it seems
they are getting narrowed down to something that could be actually
done by errata.
If we want to do something bigger we can of course do 5723bis and do
other things at the same time if needed.
Paul Wouters writes:
> > The fol
Toerless Eckert writes:
> If insights like there would be documented more prominentaly, like
> in a living IETF document, then they would fsater trickle through
> implementers.
That kind of things were usually found in the interop events where
there were few dozen vendors testing againt each other
Fernando Pereñíguez García writes:
> I note that RFC822 and RFC3280 are Obsoleted which makes their use
> problematic.
>
> [Authors] Following your recommendation, we have replaced RFC 3280 with RFC
> 5280. Regarding RFC 822, we reference it because the IKEv2 protocol
> specification (RFC
Valery Smyslov writes:
> I believe that the proper solution would be to exclude cookie from
> the AUTH payload calculation. It is verified by the responder using
> cookie generation secret and it is not concerned with a client (the
> client did not generate it, just echoes it back). However, this
>
Panwei (William) writes:
> It seems like a rare scene but I think it needs to be considered.
> Compared with ignoring cookie payload, how about adding N(COOKIE2)
> in the 9th message? Then when Initiator received the 12th message,
> it'll know which cookie this message matches with.
Actually I thi
Paul Wouters writes:
> On Tue, 22 Sep 2020, Valery Smyslov wrote:
>
> >> That is not how the CP payloads work. The initiator sends a set
> >> it is okay with and the responder picks what it prefers from that
> >> set. Or an error if it deems all of it bad.
> >
> > Exactly. However, with different
Valery Smyslov writes:
> Hi Tero,
>
> > Simple solution. Do not change cookie generation secret too often if
> > you are under attack with really crappy network...
>
> Unfortunately, RFC7296 advises just the opposite:
>
>The responder should change the value of frequently, especially
>
Valery Smyslov writes:
> Hi Tero,
>
> > > > I think the long term solution is to do puzzles, as I do not think you
> > > > need to change puzzles secrets that often compared to the cookie
> > > > secrets.
> > >
> > > Puzzle are not solution for this problem. RFC 8019 suggests that
> > > is includ
Valery Smyslov writes:
> > > For this reason RFC8019 advises to make every cookie different
> > > or at least to change the secret frequently.
> >
> > I think adding timestamp is better solution.
>
> Yes, that's what RFC8019 advises. However, this would make
> the problem with false failed authe
Lou Berger writes:
> Valery,
>
> How about this:
>
> OLD
> Receive-side operation of IP-TFS does not require any per-SA
> configuration on the receiver; as such, an IP-TFS implementation
> SHOULD support the option of switching to IP-TFS receive-side
> operation on receipt of the firs
Lou Berger writes:
> > I have to admit that I have not read this draft, but noting, that most
> > of the cipher we use do require automated key management like IKE, I
> > just wonder are you really going to be limited to 3DES, or what
> > automated key management you are going to be using instead o
Valery Smyslov writes:
> Hi Tero,
>
> > > I'm not advocating ike vs ike-less, just trying to have a comprehensive
> > > solution. One example ikeless usecase is captured by the YANG model in
> > > last call:
> > > https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
> >
> >
Christian Hopps writes:
> What is intended is that an implementation can process inbound IPTFS
> payloads w/o actually explicitly configuring the inbound SA to be in
> "IPTFS-mode" (zero-conf). That is all.
And if IKE is used what is the use case for that?
IKE allows easy way of agreeing on the
Christian Hopps writes:
> I really don't understand the extreme back pressure against using
> ESP the way it was designed. The next-header field is supposed to
> identify the payload, it does so for every other payload ESP
> carries. Any other solution to somehow infer the payload type some
> other
Christian Hopps writes:
> > Earlier there was also another encapsuluation mode called a Bound
> > End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and
> > in that case it would have been impossible to detect the mode from the
> > incoming packet, as lots of the information needed t
Christian Hopps writes:
> We are defining the payload in this document, the payload is meant
> for ESP. ESP has a payload identifier why can't we use it?
If that is only possible value the next-header field can have as all
packets of the Child SA which has been negotiated with USE_IPTFS then
what
Daniel Migault writes:
> The security consideration has been updated as follows:
>
> """
> The security of a communication provided by ESP is closely related to
> the security associated to the management of that key. This usually
> include mechanisms to prevent a nonce to repeat for exam
Daniel Migault writes:
> value SN needs to be considered instead. Note that the limit of
> messages being sent is primary determined by the security associated
> to the key rather than the SN. The security of the key used to
> encrypt decreases with the each message being sent and a n
Roman Danyliw writes:
> > >> It seems to me that the IANA entries for IKEv2 are incomplete.
> > >> RFC8247 does a fine job of specifying algorithms and adding
> > >> information such as status (MUST/SHOULD+), IoT, AEAD and so on,
> > >> information which is not present on IANA. The policy for, e.g
Daniel Migault writes:
>
> Correct. it must be a MUST. I also explicitly added that condition on nonce
> and counter needs to remain valid. The new text is as follows:
>
> When such mechanisms cannot be implemented and the session key is, for
> example, provisioned, the nodes MUST ensure that ke
tom petch writes:
> And RFC8247 specifies which algorithm are AEAD, the web page does not.
Actually RFC8247 does not specify which algorithms are AEAD. It only
specifies that information for those algorithms it lists. For example
it does not mention ENCR_AES_CCM_16 at all, thus it does not list
w
tom petch writes:
> The problem I see is where to direct readers of the i2nsf-sdn to for
> more information, about which algorithms are recommended, or not, and, a
> secondary consideration, whether they are AEAD or not, since the latter
> affects the YANG module. The I-D has lots of references
I have received three presentation requests for the IETF 109, so the
agenda for the IPsecME meeting currently looks like this:
--
- Note Well, technical difficulties and agenda bashing –
Chairs (5 min)
- Document Status –
Cha
Joseph Touch writes:
> I’m not aware that it’s possible for me to do this. It might be the
> transport chairs who do.
That is not normally done during the reviews. If the reviewer is happy
with the changes authors have done, then thats it. The document will
get rereviewed during the last call and
First, thanks for the Joe for very good TSV review for this draft.
I am now going through this draft to see whether it is ready for WGLC,
and while reviewing it I have some comments on it. On the other hand I
think it is starting to get ready for WGLC...
In section 2.2.3 fragmentation etc, the dr
Christian Hopps writes:
> Also, as per the last IETF meeting, can we please start an WG
> adoption call on the supporting YANG draft?
>
> https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/
I think this draft is not exactly in sync with the main iptfs, as it
still has some counter
Christian Hopps writes:
> I have published a new version of the draft which I believe
> addresses the issues you raise in your WGLC readiness review below.
> As such, I'd like to request the document enter WGLC.
Thanks, I will start WGLC soon.
> The lack of the assumption is also more clear wit
This is the start of 3 week WGLC on the document, ending 2021-02-15.
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
___
IPs
This is the start of 3 week WG adoption call for this document, ending
2021-02-15. Please send your reply about whether you support adopting
this document as WG document or not.
This document is not explictly mentioned in our charter, but as this
is part of the traffic flow confidentiality work th
Christian Hopps writes:
WGLC is not too late to do changes, it is quite early in the process,
we still need to go to the IETF LC, and then through IESG etc. If
making these changes now will make document easier to read, that will
most likely make IETF LC and further steps easier, so it might save
Christian Hopps writes:
> Just to clarify, are you indicating Valery's changes should be made?
> If so then I will update the document so we can continue to make
> progress.
I have not checked out the draft yet, so I do not have opinion about
this. I was just pointing out that this is good time t
Don Fedyk writes:
> Can we republish this draft as a WG ie
> draft-ietf-ipsecme-yang-iptfs-00.yang ?
There is no need for that now. The adopted WG drafts are marked as
such in the datatracker when I get that far in my process of getting
things ready for the ietf, and then when next revision of th
I quickly reviewed the draft-smyslov-ipsecme-rfc8229bis-02, or more
accurately I reviewed the diff between the rfc8229 and this draft [1]
During the review I found this text:
Additionally, since TCP headers are longer than UDP headers, and TCP
encapsulation adds a 16-bit Length fie
This is the start of 1.5 week WG adoption call for this document,
ending 2021-02-07 (just before our IPsecME session in IETF 110).
Please send your reply about whether you support adopting this
document as WG document or not.
Our charter has item for:
RFC8229, published in 2017, specifies
This is the start of 1.5 week WGLC on the document, ending 2021-03-07,
i.e. just before the IPsecME WG meeting in IETF 110. 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.
Valery Smyslov writes:
> > In section 7.3 there is text saying:
> >
> > Note that if this TCP connection is
> > closed, the Responder MUST NOT include the Initiator's TCP port
> > into the Cookie calculation (*), since the Cookie will be returned
> >
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 UD
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 dif
101 - 200 of 1364 matches
Mail list logo
