Shihang(Vincent) writes:
> Hi Tero,
> We moved our draft of IPComp extension from 6man to IPSecMe because
> people told me that IPComp IANA registry is in the IPSec. However
> the extension itself is not related to encryption. I wonder if the
> IPSecMe is the right place for the draft.
It is not,
David Dong via RT writes:
> Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG),
>
> As the designated experts for the IKEv2 Notify Message Types - Error
> Types and Status Types registries, can you review the proposed
> registrations in draft-ietf-ipsecme-multi-sa-performance-06 f
David Dong via RT writes:
> Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG),
>
> As the designated experts for the IKEv2 Notify Message Types -
> Status Types registry, can you review the proposed registration in
> draft-ietf-ipsecme-ikev2-auth-announce-06 for us? Please
Tero Kivinen has requested publication of
draft-ietf-ipsecme-multi-sa-performance-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-multi-sa-performance
I just now noticed that I never announced or marked the result of
adoptionc alls for these two docments, mostly because they expired,
and because that they did not show up in the IPsecME WG document page,
so when I searched all documents in Call for Adoption state, they did
not show up.
Now when
internet-dra...@ietf.org writes:
> Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now
> available. It is a work item of the IP Security Maintenance and Extensions
> (IPSECME) WG of the IETF.
>
>Title: IKEv2 support for per-resource Child SAs
This seems to cover my
Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or
anybody else) aware of any IPRs related to this draft?
Are authors willing to be listed as authors?
I will require response from author, and also updated version of the
draft based on my review comments, before I will hit
In section 1 Introduction:
While this could be (partially) mitigated by setting up multiple
narrowed Child SAs, for example using Populate From Packet (PFP) as
specified in [RFC4301], this IPsec feature is not widely
implemented.
I think it would be better to give better reason why
Here is the agenda for the next weeks IPsecME WG. Please submit the
slides to the datatracker before Sunday.
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 119 - Tuesday, March 19th, 2024 15:30-17:00
Xialiang\(Frank, IP Security Standard\) writes:
> We have a new draft on IKEv2 support for ShangMi cryptographic algorithm
> suites:
> https://datatracker.ietf.org/doc/draft-guo-ipsecme-ikev2-using-shangmi/.
>
> The main purpose of this draft is to describe how the Chinese mandatory and
> ISO
If you have anything that you want to be included in the IETF 119
agenda, please send email to the IPsecME WG chairs
(ipsecme-cha...@ietf.org) as soon as possible, as I will be making the
final agenda tomorrow...
--
kivi...@iki.fi
___
IPsec mailing
Valery Smyslov writes:
> > Ideally, i would even like to see a small section in G-IKEv2 that
> > outlines how GDOI extensions can be mapped to G-IKEv2 . If this
> > waas all registry entries in RFC8052, then it would IMHO even be a
> > great exercise for progressing G-IKEv2 to see if equivalent
>
Panwei \(William\) writes:
> The handling I suggest is as follows:
>
> 1) if all KE methods proposed by the initiator are unknown to the
> responder, i.e., no KE method is acceptable, then the responder replies
> NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload.
>
>
Paul Wouters writes:
> In RFC 4303 Section 3.3.3 states:
>
> Note: If a receiver chooses to not enable anti-replay for an SA, then
> the receiver SHOULD NOT negotiate ESN in an SA management protocol.
> Use of ESN creates a need for the receiver to manage the anti-replay
> window
Antony Antony writes:
> > What we are saying is do this:
> >
> > T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for
> > Child SA)
> > T=00:01 Establish 2nd Child SA using DH (lifetime 8h)
> > T=01:00 Rekey IKE SA
> > T=02:00 Rekey IKE SA
> > [...]
> > T=07:00 Rekey
Pierre Pfister (ppfister) writes:
> > Sending 144 small encrypted packets, and receiving 144 small encrypter
> > packets should not take lots of CPU power. The CREATE_CHILD_SA does
> > NOT need to do any Diffie-Hellman, and there is no public key crypto
> > on them, so it is just encrypting those
Michael Pfeiffer writes:
> 1) The main effort for "full" child SAs is not only setting them up,
> but to maintain them (rekeying, monitoring, sending heartbeats and
> the like). In our experience, this becomes especially bad when
> partial failures are possible, i.e., a strict subset of the child
Pierre Pfister \(ppfister\) writes:
> "Creating 144 IPsec SA should take less than tenth of a second.
> IKEv2 have windowing mode. With really big systems, creating more
> SAs is not an issue."
>
> We unfortunately cannot afford to throw more cores at every scaling
> issue that we have. IPsec
This is two week adoption call for
draft-mglt-ipsecme-ikev2-diet-esp-extension. If you support adopting
this document as a working group document for IPsecME to work on, and
then at some point publish this as an RFC, send comments to this list.
This adoption call ends 2023-12-13.
Note, that I do
This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
support adopting this document as a working group document for IPsecME
to work on, and then at some point publish this as an RFC, send
comments to this list.
This adoption call ends 2023-12-13.
Note, that I do want to see
This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt.
If you support adopting this document as a working group document for
IPsecME to work on, and then at some point publish this as an RFC,
send comments to this list.
This adoption call ends 2023-12-13.
Note, that I do want to
Paul Wouters writes:
> On Mon, 20 Nov 2023, Tero Kivinen wrote:
>
> > After some probing in the Prague, we managed to get good discussion
> > and reviews on this draft, and I think the consensus on the list was
> > that it should be ready to go forward.
>
> Not
Paul Wouters writes:
> What I take from this:
>
> - Maybe look at a new EAP method to prevent AUTH payload from the
>server to be send before client is authenticated.
When we were designing IKEv2 we had long discussion about who should
authenticate first. If the initiator authenticates
Pierre Pfister (ppfister) writes:
> Would it make sense to swap Steffen’s presentation with mine ? (If that’s ok
> with you Steffen ?).
Sure, I will swap them.
> A lot of what’s in their draft covers the problem statements to the sequence
> number subspaces proposal, and would be useful
Ana Minaburo writes:
> From my point of view you need to work more on your draft to be aligned with
> SCHC. This work needs a better understanding of the SCHC header compression.
> And it will be required to be worked in parallel in both SCHC and IPsecME WG.
This is just adoption call for the
Submit the slides for the presentations for IETF 118 agenda items
before Friday 3rd. If no slides are submitted by then, I assume we can
free the agenda slot, and get more time for other presentations.
--
kivi...@iki.fi
___
IPsec mailing list
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 118 - Thursday November 9th, 2023 13:00-14:30 CET
https://meetings.conf.meetecho.com/ietf118/?group=ipsecme==1
Agenda
- Note Well, technical difficulties and agenda bashing -
Chairs (5 min)
- Document Status -
Chairs (5 min)
-
Valery Smyslov writes:
> > ** Section 3.2
> >
> > If more authentication methods are defined in future, the
> > corresponding documents must describe the semantics of the
> > announcements for these methods.
> >
> > -- Should this be a s/must/MUST?
>
> With my understanding of using BCP14
I have already received few requests for the agenda items for the IETF
118 IPsecME WG meeting, but if you want to have items on the agenda on
the IETF 118, send them to ipsecme-cha...@ietf.org by the end of this
week. I will finalize the agenda during the weekend.
--
kivi...@iki.fi
This will start three week working group laste call for
draft-ietf-ipsecme-multi-sa-performance. The working group last call
will end at 2023-11-15.
Please review the document and send comments to the list if you think
it is ready for publication.
--
kivi...@iki.fi
Tero Kivinen has requested publication of
draft-ietf-ipsecme-ikev2-auth-announce-04 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-auth-announce
I would need author to reply this email and express whether there is
any IPRs related to this draft known by the authors.
--
In section 3.1 the draft says:
Instead, the initiator MAY either link the
Announcements to the CAs received in the IKE_SA_INIT response, or
Paul Wouters writes:
>In addition, IANA has added this RFC as a reference to both the ESP
>Reference and IKEv2 Reference columns for ENCR_AES_GCM entries, while
>keeping the existing references there. Also, IANA has added this RFC
>as a reference to the ESP Reference column for
Paul Wouters writes:
> See
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
>
> I noticed that the IKEv2 column for AES_GCM variants mentions RFC
> 8247. This should be RFC 8221. And for AES_CCM, the ESP and IKEv2
> columns are missing the RFC
Daniel Migault writes:
> Thanks for the comments, this matches how we envisioned to update the draft,
> except that we envisioned the responder sends a N(DSCP) and that we also
> indicated the support of the N(DSCP). I think you recommend not to have these
> two notifications, which could work for
Daniel Migault writes:
> I am coming back to one comment that has been made during the
> presentation that DSCP values do not necessarily be associated with
> a pair of SA.
>
> We want to organise tunnels where DSCP values are partitioned
> between a subset of SAs. More specifically suppose that
Paul Wouters writes:
> On Mon, 7 Aug 2023, Tero Kivinen wrote:
>
> > Of course the optimal solution would be the original sender to not
> > send 2000 byte packets, but instead fragment the packet already
> > himself to 1300 bytes and 700 bytes, but th
Michael Richardson writes:
> I'm not sure how we put more than 255 bytes in :-)
> I guess it doesn't really matter if we call it padding or not, so we can
> really just do whatever.
I was just assuming rest of the packet is "Payload data":
0 1 2
Paul Wouters writes:
> > You can't do that if DF=1, or IPv6.
> > You can form big ESP packets and then fragment them, even with IPv6.
> > DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant
> > cope with fragments.
>
> Why does any of this even matter? The applications
Michael Richardson writes:
>
> Tero Kivinen wrote:
> > I think we should use normal ESP format i.e. have ESP SPI using
> > following format:
>
> I mostly agree.
> But:
>
> > (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Antony Antony writes:
> Thanks Lorenzo for this ID.
> I believe this is a great idea. Perhaps we could consider allowing a
> non-zero ESP payload size? This would facilitate correlating responses upon
> arrival at the sender. Then I would add an ESP message, format similar to
> ICMP message.
There is one errata item for IPSECKEY WG:
https://www.rfc-editor.org/errata/eid7402
This errata correctly identifies that the algorithm fields is
8-bit field, not 7-bit field as shown in the figure. The
section 5 IANA considerations of IPsec Keying Material in DNS
We seem to have 3 open errata for IPsecME WG documents:
https://www.rfc-editor.org/errata/eid6940
For IKEv2 RFC7296 changing "the field must be empty" -> "the
SPI field must be empty" in the SPI Size field description in
section 3.10 (the errata only says section ".10",
Checking on the errata items for the old IPsec WG I found these three:
https://www.rfc-editor.org/errata/eid6953
This is against RFC2402 and the change is correct, there is
wrong section reference 3.3.2 where it should b section 3.3.3.
This should be marked as verified.
Daniel Migault writes:
> I am under the impression that if one wants to ensure that the agreed DSCP
> value takes the right SA we need to check that. As a result, I am inclined to
> have in any case a MUST be checked. I am wondering if we are expecting this
> check to take a significant overhead ?
Daniel Migault writes:
> Let me know if that text addresses your concern or if you prefer a different
> wording. I believe I should add some more specific references to 4301.
Note, that RFC4301 already describes how to handle DSCP, and your
draft would actually change mandatory features of
Tobias Brunner writes:
> It already states in section 3: "Non-optimized, regular rekey requests
> MUST always be accepted."
...
> So you're saying some configs, that are valid for regular IKEv2, will
> just not work with this extension? And we'll only know once there is
Combining those two, I
Tero Kivinen writes:
> It seems our agenda is already full. I would like to get slides for
> all presentation during next week, i.e. before the 14th Friday
> evening.
Updated version of the agenda, with some presentato
Paul Wouters writes:
> On Jul 14, 2023, at 08:21, Tero Kivinen wrote:
> >
> > It seems our agenda is already full. I would like to get slides for
> > all presentation during next week, i.e. before the 14th Friday
> > evening.
>
> I take it you mean July 21
It seems our agenda is already full. I would like to get slides for
all presentation during next week, i.e. before the 14th Friday
evening.
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 117 - Wednesday July 28th,
Send requests for IETF 117 IPsecME agenda items to the
ipsecme-cha...@ietf.org by the end of this week, so I can create the
agenda for the IPsecME WG next week.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
Andrew Cagney writes:
> > Also the section 3.10 of RFC7296 says:
> >
> > o Protocol ID (1 octet) - If this notification concerns an existing
> > SA whose SPI is given in the SPI field, this field indicates the
> > type of that SA. For notifications concerning Child SAs, this
> >
Tobias Brunner writes:
> > The SA that the initiator attempted to rekey is
> >indicated by the Protocol ID and SPI fields in the Notify payload,
> >which are copied from the Protocol ID and SPI fields in the REKEY_SA
> >notification.
>
> Hm, I just noticed that
Paul Wouters writes:
>
> We ran into an issue where we received a REKEY_SA notify with a bad
> protocol id, eg not ESP or AH. What do we do?
>
> 1) CHILD_SA_NOT_FOUND, but what should we put in the proto id field?
> 0 ? the bogus value?
> 2) It's bad, so INVALID_SYNTAX
>
> When doing 1, we
This is the copy of the status update already posted to the datatracker:
https://datatracker.ietf.org/group/ipsecme/about/status/
--
IPTFS (base draft, and yang and mib drafts), TCP Encapsulation
(rfc8229bis) were published as
If you presenting in the IPsecME in IETF 116, please post your slides
in pdf format with page numbers to the datatracker by the end of
Monday.
No slides posted, no time in agenda...
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
mohamed.boucad...@orange.com writes:
> As you can see at https://tinyurl.com/add-ike-latest, the note is
> updated as follows:
>
> Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
> attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
> included. This
Valery Smyslov writes:
> > I mean if initiator proposes:
> >
> >CP(CFG_REQUEST) =
> > INTERNAL_IP6_ADDRESS()
> > ENCDNS_IP6()
> > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
> > INTERNAL_DNS_DOMAIN()
> >
> > to indicate that it only wants to talk ENCDNS server,
mohamed.boucad...@orange.com writes:
> > But my understanding is that this is not the case here, as if you
> > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with
> > ENCDNS_IP* to implementations supporting old RFC,
>
> [Med] Responders know when it will break. They will basically supply
mohamed.boucad...@orange.com writes:
> > At the IETF process level, which I don't master, because of last
> > note in §4, shouldn't that document explicitly say it updates
> > RFC8598?
>
> [Med] We discussed this point at the time (and I was personally for
> adding the header), but we didn't
We have received requests for enough items to fill in the IPsecME
WG meeting slot, so here is the preliminary agenda for the IPsecME WG:
If you have any additional items that you would like to discuss, then
we need to start to tune down some of the presentations.
David Dong via RT writes:
> Dear Tero Kivinen and Valery Smyslov (cc: ipsecme WG),
>
> As the designated experts for the IKEv2 Configuration Payload
> Attribute Types registry, can you review the proposed registration
> in draft-ietf-ipsecme-add-ike for us? Please
So now it is time to start sending agenda items for the IETF 116
IPsecME WG meeting.
When you send your requests, please also include how much time you
think you would need for your topic.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
Benjamin Schwartz writes:
> On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson wrote:
>
> Tero Kivinen wrote:
> > I mean what should other end do if the other end says he will not
> > do anti-replay checks?
>
> Not send unique relay
Michael Richardson writes:
> Tero Kivinen wrote:
> > I mean what should other end do if the other end says he will not
> > do anti-replay checks?
>
> Not send unique relay values in the ESP.
You can already do that on multicast SAs, but for unicast SAs the
RFC430
Benjamin Schwartz writes:
> Hi IPSECME,
>
> RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is employed,
> the receiver SHOULD notify the sender, during SA establishment, if the
> receiver will not provide anti-replay protection".
>
> I haven't been able to find any mechanism
Tero Kivinen has requested publication of draft-ietf-ipsecme-labeled-ipsec-09
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-labeled-ipsec
I already send some comments, but now when I am checking the modified
draft I found some other nits, that might need to be fixed at some
point (I will still put the document forward today, authors can fix
those later when they have time, or when they have other comments
during the IETF last call
Tero Kivinen has requested publication of draft-ietf-ipsecme-add-ike-07 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-add-ike/
___
IPsec mailing
mohamed.boucad...@orange.com writes:
> This version takes into account Tero's review, mainly:
>
> * Indicate the encoding of the addresses
> * Split the ENCDNS_DIGEST_INFO figure into two
> * Add some text about CFG_ACK
> * clarify how the digest is computed
> * Add some examples
>
> and some
mohamed.boucad...@orange.com writes:
> [Med] Yes, the initiator may include a suggested ALPN (protocol) for
> example to specifically indicate it is looking for DoT (or another
> protocol). The initiator may omit the ADN, but only include service
> parameters (typically, ALPN) to indicate a
mohamed.boucad...@orange.com writes:
> > of the cases the information in IANA registries are already in the
> > normative reference RFCs
>
> RFCs may include stale/inaccurate values (e.g., new/deprecated
> values). The IANA registry is authoritative.
Yes, but you only need one value to actually
Valery Smyslov writes:
> Hi Tero,
>
> few comments inline.
>
> [a lot of text snipped]
>
> > This document should simply say that TS_SECLABEL MUST NOT be used
> > alone. This document must not try to do incompatible change to the
> > base RFC7296 which would make conforming implemntations
> >
mohamed.boucad...@orange.com writes:
> > > Also the text in Num Addresses indicate that it would be valid
> > to send
> > > CFG_REQUEST with proposed Service Priority, but having Num
> > Addresses
> > > set to zero?
> > >
> > > Is this intended? I.e., is the client allowed to request data,
> > but
Valery Smyslov writes:
> > In section 3.2 it is not clear what the length of the Hash Algorithm
> > Identifiers fields is. It contains list of hash algorithms or one hash
> > algorithm if this is response, but it is not clear what is response.
>
> What was meant is that a list of hashes is sent
Here are some my review comments while reading
draft-ietf-ipsecme-add-ike:
--
The text in section 3.1 should say that if length is 0, then no
Service Priority, Num Addresses etc fields are present.
I.e., add text in first bullet
Paul Wouters writes:
> On Fri, Sep 23, 2022 at 1:15 PM Paul Wouters wrote:
>
> On Mon, Jul 25, 2022 at 10:24 PM Tero Kivinen wrote:
>
> Labeled IPsec is ready for publication and
> will be submitted to the IESG immediately after this IETF.
>
Murray Kucherawy via Datatracker writes:
> The document shepherd writeup says:
>
> --
> 15. Should any informative references be normative or vice-versa?
>
> Yes.
> --
>
> I'm assuming the shepherd just ran over the question too quickly.
> But, if you really meant "Yes" here, what's the plan to
I started WG adoption call of this draft about month ago, and there
has been several people supporting the adopting and publishing this
document quickly. And as has not been any opposition to adopt this
document, so the WG adoption call passes.
--
kivi...@iki.fi
I started WG adoption call of this draft about a month ago and while
there were some opposition to adopt this draft, I think they were
mostly because they thought this document does not go far enough and
does not solve all the problems in this space.
I think there was enough support for adopting
I started this last call almost a month ago, and I have not seen any
discussion, comments or emails on the ipsec list.
For me that would indicate that nobody has actually reviewed the
document during the WGLC, and would indicate there is very little
interest in publishing this document.
I will
John Mattsson writes:
> Not too late to change. According to NIST, 2048-bit MODP Group and 224-bit
> Random ECP Group are MUST NOT use if the information you are protecting have a
> lifetime longer than 8 years (2031 - today). 1024-bit MODP is two security
> levels below that. I think IETF in
Paul Wouters writes:
> ps. Re-reading this draft, does anyone remember why we deprecated DH22
> (1024-bit MODP Group with 160-bit Prime Order Subgroup) but not DH2
> (also 1024 bit MODP)
>From 8247:
...
Group 2 or the 1024-bit MODP Group has been downgraded from MUST- in
RFC 4307 to SHOULD
This is two week working roup adoption call for he
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. If you support
adoption of this document to the IPsecME WG send email to the list
before the 2022-11-24.
Note, that this is starting point for the document, so if you have any
comments send them to
This is two week working group adoption call for the
draft-pwouters-ipsecme-multi-sa-performance. If you support adoption
of this document to the IPsecME WG send email to the list before the
2022-11-24.
Note, that this is starting point for the document, so if you have any
comments send them to
This will start the 2 week working group last call document for
draft-ietf-ipsecme-ikev2-auth-announce. The working group last call
will end at 2022-11-24.
Please review the document and send comment to the list if you think
it is ready for publication.
--
kivi...@iki.fi
Some people have been asking that we add related RFCs to the IPsecME
datatracker documents page. I did it now, I added most of those
documents which are referenced from the IKEv2 IANA page. I did leave
out mobile ip, and fibre channel documents.
If anything is missing or there is RFCs that should
Robert Moskowitz writes:
> > Value Description Format description Reference
> > 0 No key is present[RFC4025]
> > 1 A DSA Public Key [RFC2536] Section 2 [RFC4025]
> > 2 A RSA Public Key [RFC3110] Section 2
Robert Moskowitz writes:
> > Value Description
> >
> > 1A DSA Public Key is present, in the format defined in [RFC2536]
> > 2A RSA Public Key is present, in the format defined in [RFC3110]
> > 3An ECDSA Public Key is present, in the format defined in [RFC6605]
>
> I can remove the
to...@strayalpha.com writes:
> > The normal case to do that is that IPsec SGW keeps track of the size
> > of packets that are ok, and which are too big based on the information
> > it receives. I.e., it might have received unsecured ICMP PTB message
> > from the network for its own Child SA, but
to...@strayalpha.com writes:
> In the best case scenario, the security gateway informs the source node to
> reduce the size of the inner packet with an ICP PTB packet for example.
>
> How? It can’t send an ICMP because it doesn’t have *the* packet causing the
> problem to “reflect” back
Valery Smyslov writes:
> > There is no point of one having for example 10 fast cpus sending
> > traffic over 10 Child SA, when the receiving end only has two cpus
> > which are about same than the other ends cpus. The receiving end will
> > not be able to keep up with the traffic it is getting in,
Paul Ponchon \(pponchon\) writes:
> > > Using different real child SA’s was needed to ensure the
> > > cryptographic security properties.
>
> Is this requirement only based on not reusing the same IV on different cores
> or is there an additional factor I missed?
IV space and replay counter are
[Replying to this email, but commenting about the others also]
Paul Wouters writes:
> On Oct 21, 2022, at 03:37, Steffen Klassert
> wrote:
> > Another possibility would be to use the same keymat on all
> > percpu SAs
>
> You cannot do that. You need to ensure unique IVs for AEAD so you
> would
Roman Danyliw writes:
> ** Section 3.2.4.
>
> The responder MUST handle this
>situation gracefully and delete the associated state if it does not
>receive the next expected IKE_FOLLOWUP_KE request after some
>reasonable period of time.
>
> Is there a
Murray S. Kucherawy writes:
> This posture worries me. I've no doubt that you're doing a fine job as the DE
> for the registries for which you're responsible, probably because you were
> around during IPSec's development. But what about your successor(s)? Will
> they have all of the context,
Murray Kucherawy via Datatracker writes:
> --
> DISCUSS:
> --
>
> Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a
> registry, Section
Erik Kline writes:
>
>
>
> > I.e., either this document needs to formally update RFC 4303 by allowing
> any
> > number or another IP protocol number must be requested to the IANA.
>
> As I pointed out in my previous email that is not the case.
>
> The RFC4303 ESP
Éric Vyncke via Datatracker writes:
> ## DISCUSS
>
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion on the following topics:
>
> ### Section 6.1
>
> ```
>An AGGFRAG payload is identified by the ESP Next Header
Robert Moskowitz writes:
> So I think the correct example should be:
>
> foo.example.com IN IPSECKEY
> (10 0 4 . 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= )
>
> I will fix my example. Do you think I should have both examples: with and
> without gateway?
More examples
1 - 100 of 1088 matches
Mail list logo
