[not waring any hats]
Paul Wouters writes:
> As explains in another thread on the list, that just complicates sending
> this information down to a locally running DNS server. None of the
> current ones take DNS wireformat for on-the-fly reconfiguration.
> However, they do take DNS presentation
Yoav Nir writes:
> Hi.
>
> New in this version:
> - A few textual changes in the Introduction (suggested by Tero)
You seemed to skip my proposed changes for the IANA considerations
section. As an IANA expert, I would be more happy with the actual
table version of the allocations there, as it
Paul Hoffman writes:
> On 5 Aug 2016, at 8:23, Yaron Sheffer wrote:
>
> > The trick to that is to add a new column to the IANA table
> > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
>
> That's the first of two tricks: the second is getting agreement
Valery Smyslov writes:
> > I think this document should update 7296 due to adding non-encrypted
> > payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that
> > is not allowed. Someone implementing 7296 should be aware of it to allow
> > it in their implementation.
>
> Hmmm... Not
[This replies to emails other people also sent to list, but I just
picked the last email to list some points, and I am talking here as an
implementor not as a chair].
David McGrew writes:
> Yes; that draft is a good starting point. The goal should be to
> develop an RFC that updates RFC 7383 and
The authors of the draft-pauly-ipsecme-split-dns has asked the early
IANA code point allocation for the INTERNAL_DNS_DOMAIN specified in
draft-pauly-ipsecme-split-dns. This request only covers
INTERNAL_DNS_DOMAIN and does NOT include INTERNAL_DNSSEC_TA.
As a WG chair I have checked the request,
This message will start two week working group last call for the
draft-nir-ipsecme-eddsa-00 [1] draft.
Please send your comments, questions etc to WG mailing list before
2017-02-24. If you belive that the document is ready to be submitted
to the IESG for consideration as a standard track RFC
I think we have still enough drafts going forward and work to do that
is useful for us to meet in the Chicago. I am planning to put in a
request for one 1.5 hour session, but if someone has some other agenda
items which are not in our current items to be worked on (rfc4307bis,
rfc7321bis, eddsa,
Sandeep Kampati writes:
> 3.5. Identification Payloads
>
> ID_IPV4_ADDR1
> A single four (4) octet IPv4 address.
>
> Questions: do we need to consider "single four (4) octet IPv4
> address" as MUST point and reject the packet if we receive more
> length for it.
Ah I noticed that my last call email had wrong draft name in the
subject line and in the link. The correct draft name is of course
draft-ietf-ipsecme-eddsa-00 not *-nir-* version.
David Schinazi writes:
> I've reviewed this draft. I support it and believe it is ready to move forward
> towards
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:
> http://www.rfc-editor.org/errata_search.php?rfc=7296=4930
>
>
IETF 98 session request done for 1.5 hours.
Agenda could be:
- Document status of "finished" documents
- rfc4307bis
- rfc7321bis
- Document status of "almost finished" documents
- EdDSA
- tcp-encaps
- Document status of other adopted WG drafts
- split-dns
- Work items
- Quantum
Andreas Steffen writes:
> I personally think that 0 would have been legitimate for the "Identity"
> hash but the next unassigned value (5) is also ok for me.
>
> Could you please ask IANA for an early assignment of the code point?
> strongSwan 5.5.2 with Ed25519 support is ready to be deployed,
>
Scott Fluhrer (sfluhrer) writes:
> > Or could we introduce some things now that would make "dropping in" a
> > replacement easier?
>
> Nothing comes to mind; according to the above wild speculation, the
> difficulties that people are likely to encounter are more to do with
> the implementations,
kathleen.moriarty.i...@gmail.com writes:
> Could you respond on the timeline and if you think it's reasonable
> and why or if it should be changed.
Sure.
Out of the nine documents to be published, there is two which are
already going out from the WG, i.e., which are already submitted for
Yaron Sheffer writes:
> Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with
> lossless algorithms. And as far as I know, they are applicable to any
> situation where here is an attacker that can force traffic on the wire,
> mixed with other, non-attacker controlled traffic.
Mirja Kuehlewind writes:
> Similar to Spencer's commet I have problems understanding what the
> following really means:
>
> "To make IKE work in these environments, IKE packets need to be
> encapsulated in a TCP tunnel. The group will define a mechanism to
> tunnel IKE and IPsec over a TCP-based
Kathleen Moriarty writes:
> >> "There have been middle boxes blocking IKE negotiation over UDP. To
> >> make IKE work in these environments, IKE packets need to be
> >> encapsulated in a TCP tunnel.
> >
> >
> > "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
> > tunnel was
this might be the right group. If there is an unknown number of open
> questions to be answers, it might not.
I think the current draft mostly already answers to the questions, and
I do not think there are that many open issues with it.
> > Am 31.08.2016 um 13:57 schrieb Tero Ki
Mirja Kuehlewind (IETF) writes:
> thanks for providing the reference to the draft. That was very
> helpful and confirmed my initial assumption that you don’t want to
> ‚change‘ TCP. So this work seems to be fine in this group, however,
> the wording in the charter is very misleading. What's about
Both of them still miss the summary of changes since 4307 and and 7321
sections.
Now when we hopefully have agreed on what changes are going to make,
so we might want to add summaries:
--
Algorithms mentioned in the RFC4307
Paul Wouters writes:
> I'm really against this solution. As you said, we can expect more of
> this with ECC variants, and it will just be a large cluttering of the
> integ registry.
Do you really think we will see this more in ECC? How will that happen
more in the ECC?
If I have Ed25519 key, why
Valery Smyslov writes:
> The reasons can be various. For example, after wide adoption
> of EdDSA some vulnerability is found in the scheme and some
> modifications are introduced to eliminate it (analogously to
If there would be vulnerability in the signature scheme, I think we
would say you
I think this document is still waiting for curdle to finalize the
OIDs, but otherwise I think it is in good shape, so we should adopt
this document for WG document now, so we can go forward when curdle
gets its document ready.
So this is 2 week call for adoptation of the
[This is bit old email, but I have not seen any replies to this, and I
am sending this as implementor not as chair.]
Valery Smyslov writes:
> The problem is that RFC7427 doesn't provide any means to find out
> what kind of signatures peer supports. If you have RSA certificate,
> you need somehow
Paul Wouters writes:
> > Section 4.2
> >
> > | RSASSA-PSS with Empty Parameters | MUST NOT | |
> > | RSASSA-PSS with Default Parameters | MUST NOT | |
> >
> > Well, I'm a confused with these requirements. As far as I
> > understand the RSASSA-PSS parameters default
Ben Campbell writes:
> --
> COMMENT:
> --
>
> The milestones are all in the past. Should 2016 be 2017? Also, I notice
> the milestone list does not cover the
Charter update
New version posted to list 2016-07-20, no objection in list, should
go forward, on the 2016-09-01 IESG telechat.
Document Status:
- draft-ietf-ipsecme-ddos-protection (David)
WGLC should be done, ready to go forward.
- draft-ietf-ipsecme-rfc4307bis (David)
Should be
Tero Kivinen writes:
> Now when we have new version of the draft-ietf-ipsecme-safecurves, so
> I will now start two week working group last call (WGLC) for
> draft-ietf-ipsecme-safecurves-03 [1].
>
> Please send your comments, questions etc to the WG mailing list before
>
Wang Jian writes:
> The MFA we finally implemented is like
>
> 1. Users first authenticate themselves with username & password
I.e., some suitable EAP method.
> 2. according to the user's security group, another OTP authentication
> step is needed or not. For users that OTP is needed, OTP
>
Yoav Nir writes:
> I’m not entirely comfortable with calling something a MUST NOT when all we
> have is conjecture, but I have no love and no need of those DH groups.
Same here, and it also makes it so that we cannot say our
implementation is conforming rfc4307bis, even when we do already have
Yoav Nir writes:
> > Same here, and it also makes it so that we cannot say our
> > implementation is conforming rfc4307bis, even when we do already have
> > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to
> > implement algorithms in the new document, but we do also have code to
> >
Paul Wouters writes:
> Has anyone done support for SCTP in IKEv2 ? (or even in IKEv1?)
>
> If so, how are the SA's negotiated? a matrix of src/dst addresses
> as seperate CREATE_CHILD_SA's ? Or multiple traffic selector payloads
> in a single CHILD SA?
>
> It seems IKEv1 ID_LIST is not present
Paul Wouters writes:
> Tero: Agenda talk
> Tero: ddos and safecurves in AUTH48
...
Thanks for writing the minutes. I cleaned them up a bit, and posted
them the datatracker.
If there are any more comments or corrections to the minutes, please
send them to me.
Minutes can be found from the end of
Watson Ladd writes:
> I might be confused, but the slides in
> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf
> seem to very clearly want something else. Apologies for my
> insufficient context inclusion.
Yes, with RSA I think it might be
Agenda of IETF 97, Seoul posted:
Tuesday, November 15, 2016
13:30-15:30 Tuesday Afternoon session I
- Agenda bashing, adminstrivia - Chairs (5 min)
- Status of ready WG drafts - Chairs (5 min)
(ddos-protection, safecurves, rfc4307bis, rfc7321bis)
Michael Richardson writes:
> > - Authentication; if someone with a Quantum Computer can break the DH
> > in real time, do we care if he can act as a man-in-the-middle? Scott
> > Fluhrer: not important Michael Richardson: important, provided that we
> > don't run into the same
Stephen Farrell writes:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-ipsecme-safecurves-05: Yes
>
> --
> COMMENT:
> --
> - Sorry
Valery Smyslov writes:
> CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But
> CREATE_CHILD_SA doesn’t allow to exchange identities. So, if
> pseudonyms were used in IKE_AUTH, how are you going to exchange real
> identities?
Real IDs are never exchanged over wire. The server sees
Paul Wouters writes:
> >> If we assume rfc7431bis can be used with manual keys too, we need to add
> >> some more text saying these ciphers cannot be used with manual keys.
>
> >> Anyways, I think it should be time to mark manual keys as SHOULD NOT.
>
> While I agree, I don't think 7321bis
Michael Richardson writes:
> > o Valery Smyslov gave a suggestion that we instead stir in the PPK
> > into the initial SK_d; as all keying material is generated based on
> > that, this would also mean that IPsec SAs and any child IKE SAs are
> > also protected. This also means that
This message will start two week working group last call for the
draft-ietf-ipsecme-tcp-encaps-04 [1] draft.
Please send your comments, questions etc to WG mailing list before
2017-01-29. If you belive that the document is ready to be submitted
to the IESG for consideration as a standard track
This draft should be quite ready for the WGLC, so I will start that
shortly, but here are comments from my chair review of the draft.
Consider these comments just like any WGLC comments.
--
In section 6, there is text saying:
In order to close an IKE session, either the initiator or
Valery Smyslov writes:
> > Initiator then recreates tcp session with responder and sends some ESP
> > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
> > TCP connection, creates completely new TCP session and replays the old
> > ESP message with sequence number of 0x1000 (which
Valery Smyslov writes:
> > > > This way if you have originally configured company1.com to the
> > > > internal dns names, and then company decides to buy another company
> > > > called company2.com, teh client can still request company1.com and
> > > > server can return both company1.com and
Valery Smyslov writes:
> > This should be happening anyways, as there will not be reordering happening
> > inside the TCP connection, so this will not cause issues for normal
> > cases.
> >
> > Same for the IKE SA, i.e. the message-id must be larger than anything
> > seen before, not just
Timothy Carlin writes:
> My comments:
>
> * Section 4 mentions that that 256-bit keys are raised to the SHOULD level.
> Should this read as these are now the MUST level as ENCR_AES_CBC and
> ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the [1]
> endnote)?
Yes, I think this
Valery Smyslov writes:
> > This way if you have originally configured company1.com to the
> > internal dns names, and then company decides to buy another company
> > called company2.com, teh client can still request company1.com and
> > server can return both company1.com and company2.com in its
Valery Smyslov writes:
> > > > Initiator then recreates tcp session with responder and sends some ESP
> > > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
> > > > TCP connection, creates completely new TCP session and replays the old
> > > > ESP message with sequence number
Paul Wouters writes:
> > Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of
> > policy reasons, then it is not internal name anymore, thus it can use
> > DNS server configured elsewhere. But yes, I agree there should be
> > clarification explaining that only those internal names
Tommy Pauly writes:
> This MUST should probably be downgraded to a SHOULD, and add
> explanation about the reuse case. The point of this text was to make
> sure that initiators don’t needlessly leave TCP connections open to
> responders, and take up resources on the responder. A better text
>
Michael Richardson writes:
> > This has the issue that differences in the PPK will not be detected,
> > i.e., if PPKs are mismatched because of configuration error, we do get
> > IKEv2 SA up and running, and we create IPsec Child SAs without errors,
> > but then all traffic in
Michael Richardson writes:
> > If server side identity protection is also needed, then server side IDr
> > would also be similar pseudonym, but that would require server to keep
> > track of which IDr was given to which client, and pick suitable IDr
> > based on the IDi coming in.
Michael Richardson writes:
>
> Tero Kivinen <kivi...@iki.fi> wrote:
> > That is why I think it is important that we do detect the failures
> > correctly.
>
> >> > SK_d provides quantum resistance for the IPsec SAs and Child IKE
> &
Scott Fluhrer (sfluhrer) writes:
> o There is the option listed in the draft, where we modify both the KEYMAT
> and SKEYSEED computations; stirring it into the KEYMAT implies that the IPsec
> SAs are generated with QR-resistant keying material, while stirring it into
> the SKEYSEED implies that
Valery Smyslov writes:
> Hi Tero,
>
> > > CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But
> > > CREATE_CHILD_SA doesn’t allow to exchange identities. So, if
> > > pseudonyms were used in IKE_AUTH, how are you going to exchange real
> > > identities?
> >
> > Real IDs are never
This document was marked as "waiting for more reviews before taking as
WG draft", so I did my review now. Here are my comments:
--
In the section 1 there is text:
The client device
can use the internal DNS
The RFC4301 requires support for manual keys (section 4.5), but I hope
nobody really uses them. The rfc7321bis provides mandatory to
implement algorithms for the IKEv2 use, and does not really
specifically cover manual keys cases, but it does not really say that
manual keyed SAs are out of scope
Paul Wouters writes:
> > When an IPsec connection is terminated, the DNS forwarding must be
> > unconfigured. The DNS forwarding itself MUST be be deleted. All
> > cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be
> > flushed. This includes negative cache entries.
Paul Wouters writes:
> > -3: I wonder why "... is not to be used..." is not "... MUST NOT be
> > used...". But the section goes on to say if you do it anyway, you MUST
> > NOT use certain cryptosuites. So, does "... is not to be used..." mean
> > "SHOULD NOT"? Or is this one of those "MUST NOT BUT
Kathleen Moriarty writes:
> Sorry I dropped the ball. I can start IETF last call, but since we
> are in IETF week, should it be extended a week?
Yes, I think extending it by a week would be better.
--
kivi...@iki.fi
___
IPsec mailing list
Daniel Migault writes:
> For unicast communications, a single SPI can be used over multiple
> nodes as long as the remote peer, as long as both nodes uses IP
> addresses and SPI to index the SAs. With the transport mode, the
> number of SPI is equivalent to the number of hosts, while with
> tunnel
Here is the current status of the working group documents:
--
Document Status:
- draft-ietf-ipsecme-rfc4307bis (David)
Approved. Revised ID already done.
- draft-ietf-ipsecme-rfc7321bis (David)
Approved. Revised ID needed.
As discussed in the meeting, we are starting two week working group
adoptation call for the draft-mglt-ipsecme-implicit-iv.
Please read the draft and send your comments to this list, and also
tell if you support adoptation of this draft as WG draft.
The document is available at
Here are the preliminary minutes of the IPsecME meeting in Chicago.
Send corrections, and additions etc to me.
Thanks to Michael and Tommy for taking the minutes.
--
IPSECme meeting.
IETF98.
Tero and David as Chairs.
Room
So I have proposed earlier that we should mix the ppk to SK_d, SK_pi,
and SK_pr, i.e., something like this:
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'}
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
If no
Valery Smyslov writes:
> > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the
> > IKEv2 authentication will fail, and we will get exactly same failure
> > for wrong PPK than we do with wrong shared key or digital signature
> > failures. This means that attacker do not gain any
[Not wearing any hats]
Scott Fluhrer (sfluhrer) writes:
> - Move the notifies to the prior messages (that is, in the clear).
> If we do this, then by the time we derive keys, we know whether
> we're using a PPK (even if the responder doesn't know which one it
> is until it hears the initiator's
Valery Smyslov writes:
> Hi Tero,
>
> > I.e., when you configure node A for PPK use, you need to give node A
> > all the PPKs for all peers it has. I.e., the configuration loaded on
> > the node A needs to provide all PPKs it will need.
>
> If node A is mostly an initiator (e.g. a remote access
Now the pre-hash algorithms are SHOULD NOT:
The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
respectively) SHOULD NOT be used in IKE.
I think we could say MUST NOT be used.
I.e, say that pre-hash versions MUST NOT be used, and that Ed25519 and
Ed448 MUST be used with
Michael Richardson writes:
>
> Tero Kivinen <kivi...@iki.fi> wrote:
> > Scott Fluhrer (sfluhrer) writes:
> >> Going through this suggestion (and tweaking it a bit):
> >>
> >> Pluses: - I believe it can be made a bit more flexible th
Scott Fluhrer (sfluhrer) writes:
> I've been pondering another question, and I think I'll bring it up
> before finalizing the next version of the draft.
>
> After the WG meeting, we (Tero and myself) met in the hallway and
> had a little chat. One of the things that I took away from it (and
>
Michael Richardson writes:
> linda> Is the "INTERNAL_IP4_ADDRESS" in RFC5996 intended for establishing
> linda> IPSec tunnel between remote VMs behind NAPT (all VMs have the virtual
> linda> IP address)?
> This is used when transport mode is used through a NAPT.
> It doesn't apply to tunnel mode.
Paul Wouters writes:
> On Tue, 4 Apr 2017, Tero Kivinen wrote:
>
> > N(PPK_SUPPORTED) -->
>
> > For example if the PPKs are taken from the 1GB one-time-pad file
> > shared by the peers (one file per user), then the ppk_id could simply
> > be 32-bit offs
Scott Fluhrer (sfluhrer) writes:
> Going through this suggestion (and tweaking it a bit):
>
> Pluses:
> - I believe it can be made a bit more flexible than you make it out;
> it don't believe that you actually need to update every node with
> every PPK at the start. With this protocol, the
Scott Fluhrer (sfluhrer) writes:
> With your idea, there are three steps (and so the admin would update
> each node in the network twice):
>
> - Step 0 is "never use PPKs"; we're running the standard IKE protocol.
> - Step 1 is "if we're the initiator, then use PPKs if the responder
>
Michael Richardson writes:
> I don't think we need to do this.
> I think that unknown transform types will be ignored by compliant
> implementations.
Nope. It will ignore unknown transform IDs for each known transform
type, but it MUST understand each transform type, and if it does not
understand
Daniel Van Geest writes:
> 1) QS SA Negotiation
>
> When negotiating a QS SA, it’s not enough to negotiate QS key
> agreement algorithm(s), one also has to ensure that the algorithms
> selected by the other transform types are also QS.
All of these kind of issues are really policy matters, thus
Valery Smyslov writes:
> I'm very much concerned with the IKE-less option presented in the
> draft.
>
> First, the Network Controller becomes a very attractive target for
> attacks in this case, since an attacker, if attack is successful,
> will gain all the keys for the whole system.
And it is
Rafa Marin-Lopez writes:
> I.e. any TLA would love to get their hands on all the traffic keys in
> one location, and then be able to decrypt any traffic going inside any
> of the IPsec tunnels.
>
> If controller only has the PSKs or similar to do the authentication
>
Here are the minutes of the meeting (thanks Yaron), if you have fixes,
additions etc to them send them to me. I will post these to the
meeting materials next week.
--
Minutes of the IETF 99 IPsecME WG meeting Prague 2017-07-21.
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:
> http://www.rfc-editor.org/errata/eid5056
>
>
Tommy Pauly writes:
> > --
> > DISCUSS:
> > --
> >
> > This draft suggests that ports that are assigned to other services can
> > simply be used. This is not
Ben Campbell writes:
> --
> COMMENT:
> --
>
> Substantive Comments:
>
> -3, first paragraph:
> Are people confident there will never, ever be a need to demux
Paul Wouters writes:
> On Tue, 25 Apr 2017, Joe Touch wrote:
> > Every bit pattern, including those using magic numbers, is already
> > owned and under the control of each assigned port. It is not
> > appropriate for any new service to hijack that pattern as having a
> > different meaning UNLESS
Eric Rescorla writes:
> AFAICT there are two separate issues:
>
> - The use of 4500, which, as Tero says, we can just update the registry to
> point to this document for.
> - The use of 443, which seems more complicated
Yes.
> WRT 443, I would assert the following facts:
>
> - It's not
Spencer Dawkins at IETF writes:
> The reason optional ports in URIs work, is that someone handed you a URI with
> that port number who has some reason to believe that the port number is OK to
> use with the host included in the URI.
>
> Is that a reasonable assumption about the way IPsec and IKE
Mirja Kühlewind writes:
> > I agree that this kind of port squatting is regrettable, but I also don't
> > think it really
> > helps to not publish RFCs that document widely used protocols because we
> > are sad they port-squatted.
> >
> > I proposed a way to deal with this in an earlier e-mail.
Ben Campbell writes:
>
> > On Apr 26, 2017, at 6:06 AM, Tero Kivinen <kivi...@iki.fi> wrote:
> >
> > Ben Campbell writes:
> >> ---
Linda Dunbar writes:
> Can you add I2NSF to the "Conflict to Avoid" list?
Seems, I can't do that, when I try I get "The page you were looking
for coundn't be found" error...
Ah, found another route which gave me correct url. Added now...
And next I need to write a ticket about the wrong url...
Valery Smyslov writes:
> It is not clear for me (and I raised this concern in Prague) why do
> you use QSKE as an additional Key Exchange mechanism instead of
> replacing DH KE with it? We’ve been being told by cryptographers
> that conventional public key cryptography won’t provide security in
>
Cen Jung Tjhai writes:
>>And I think if the IKE_SA_INIT messages grow too large with QSKE,
>>then it’s better to develop generic fragmentation mechanism for
>>IKE_SA_INIT, rather than making it specific for fragmenting QSKE
>>blobs. Generic mechanism would allow to reuse it in case we’ll have
>>to
Paul Wouters writes:
> Received PPK_SUPPORT Have PPK PPK MandatoryAction
> --
> Yes No *Standard IKE protocol
> Yes Yes *Include
Tommy Pauly writes:
> However:
> a) That’s in a paragraph that starts “If a TCP connection is being
> used to resume a previous IKE session…”; does it apply only in that case?
>
> No, the MUST close applies for all connections, regardless of resumption. We
> could add a paragraph
Yoav Nir writes:
> But since Tommy’s happy with tearing down the connection after one invalid
> SPI, that solves the problem nicely.
I do not think we want to do that. There are valid cases where we
might get unknown SPIs, so tearing connection down after one of those
is not good solution.
> By
Tommy Pauly writes:
> I'll defer to Tero on this one. Tero, what do you prefer to do with the IANA
> Considerations text?
[Note, that I am just talking as individual here, these IANA actions
do not relate the IKEv2 registries where I am IANA Expert]
I proposed to change both the UDP and TCP
Mirja Kuehlewind (IETF) writes:
> my thinking was that the main problem is that 3947 was not obsoleted
> and I’m assuming we need a document to fix that.
This is partly issue, but it is not issue we need to solve here, as
this document is not something that should obsolete 3947.
Also 3947 only
Mirja Kuehlewind (IETF) writes:
> so first updating is a request to IANA, so you have to remove the
> first sentence.
Agreed, forgot to remove that.
> Then the update of the UPD port should probably be done in a
> separate document that potentially also obsoletes 3947 if that was
> missed with
Black, David writes:
> Well, RFC 5282 actually prohibits the responder from selecting that
> combination, but requiring separate proposals for combined-mode and normal
> ciphers is a cleaner and simpler approach.
Yes, and RFC5996 restricted that even more, saying that you need to
use separate
Paul Wouters writes:
> > for 8, 12, 16 octet versions came to be 18, 19, and 20, and the number
> > 17 which was most likely allocated for the 4 octet ICV was marked as
> > reserved.
>
> Except it is marked unassigned, not reserved. So one could use this
> number in the future. I for sure have
601 - 700 of 1088 matches
Mail list logo
