[IPsec] Protocol Action: 'Curve25519 and Curve448 for IKEv2 Key Agreement' to Proposed Standard (draft-ietf-ipsecme-safecurves-05.txt)

[The IESG]

The IESG has approved the following document:
- 'Curve25519 and Curve448 for IKEv2 Key Agreement'
  (draft-ietf-ipsecme-safecurves-05.txt) as Proposed Standard

This document is the product of the IP Security Maintenance and
Extensions Working Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/




Technical Summary

  This document describes the use of Curve25519 and Curve448 for
  ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol.

Working Group Summary

The document did not get many comments in the IPsecME working group.
However, this document mostly reuses RFC7748 content defining the
Diffie-Hellman groups, as such, this was expected. This document
defines how those groups are used in the IKE.

Document Quality

Although there are no implementations yet, some are planned and are pending on 
the IANA allocations.

Personnel

Kathleen Moriarty is the responsible Area Director. 
Tero Kivinen is the document shepherd.

IANA Note

  IANA is requested to assign two values from the IKEv2 "Transform Type
   4 - Diffie-Hellman Group Transform IDs" registry.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

[Tommy Pauly]

Hi Jun,

You’re correct that the draft does not specifically call out using multiple TCP 
connections for a single Child SA. It explains that one reason to use multiple 
TCP connections is to handle “connect[ing] to multiple gateways handling 
different ESP SAs”, which is the one-child-SA-per-TCP model. There is nothing 
in the protocol prohibiting using multiple TCP connections for a single child 
SA; what is your main use case here? Is there something that you find useful in 
that that could perhaps help inform this clarifying text?

Tommy

> On Oct 11, 2016, at 8:42 PM, Hu, Jun (Nokia - US)  wrote:
> 
> From the section 6 text, my understanding is draft allows multiple TCP 
> connections for a given tunnel which includes multiple CHILD_SAs; however it 
> is not clear to me that draft also allows multiple TCP session for a single 
> SA, is there any use case of having multiple TCP sessions for a single 
> CHILD_SA?
>  
>  
> From: tpa...@apple.com [mailto:tpa...@apple.com] 
> Sent: Tuesday, October 11, 2016 5:35 PM
> To: Hu, Jun (Nokia - US)
> Cc: Valery Smyslov; Yoav Nir; IPsecME WG; Daniel Migault; Paul Wouters
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for 
> adoption
>  
> Please see section 6:
>  
>  Multiple TCP connections between the initiator and the responder are
>allowed, but their use must take into account the initiator
>capabilities and the deployment model such as to connect to multiple
>gateways handling different ESP SAs when deployed in a high
>availability model.  It is also possible to negotiate multiple IKE
>SAs over the same TCP connection.
>  
>The processing of the TCP packets is the same whether its within a
>single or multiple TCP connections.
> 
> We believe this text is fairly direct in specifying that multiple IKE SAs can 
> go over a single TCP stream, and that multiple TCP streams are allowed for a 
> single IKE SA/Child SA set. There is no dependency between the TCP streams 
> and the IKE or Child SAs. We recommend a 1-to-1 correspondence for 
> simplicity, but there is no technical limitation. The TCP streams should not 
> necessarily be closed or reset if the SA sends data on a different flow.
> 
> Thanks,
> Tommy
>  
>  
> On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US)  > wrote:
>  
> Any comments to my questions below?
> Does draft allows multiple TCP sessions for a given SA? Or it should be only 
> one TCP session allowed for a given SA?
> 
> 
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org ] 
> On Behalf Of Hu, Jun (Nokia - US)
> Sent: Friday, October 07, 2016 2:09 PM
> To: Tommy Pauly; Valery Smyslov; Yoav Nir
> Cc: IPsecME WG; Daniel Migault; Paul Wouters
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
> adoption
> 
> I was reading the draft again, and had similar problem as below; Draft states
> that SA state should be independent of TCP state and it allows multiple TCP
> sessions between two peers even when there is only one IKE_SA; I assume this
> means for a given tunnel, different SA could belong to different TCP session,
> e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does
> this mean draft allows multiple TCP sessions for a given SA? I guess not, if
> that's the case, then it should be stated clearly in the draft that for a 
> given SA,
> only one TCP session is allowed; In case of when the original initiator lost 
> TCP
> session and create a new one, the responder should update its TCP_session-
> to-SA binding after it receives a valid IKE/ESP packet is received on the new
> TCP session and close the old one, send TCP RST
> 
> 
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org ] 
> On Behalf Of Tommy Pauly
> ...
> 
> 
> Then, I think some text should be added describing a situation when
> the original responder having a valid (from its point of view) TCP
> session receives a request from original initiator for a new TCP
> session. This may happen if original initiator looses TCP state for
> some reason (RST from an attacker, temporary network failure etc.).
> In this case the responder will have two TCP sessions associated
> with the IKE SA. Clearly, the new one should be used for further
> communications, but only after it is proven to be authentic (some
> protected message is received over it). But what the responder
> should do
> with the old TCP session?
> 
> Keep it? Send FIN? Send RST? Just discard?
> 
> 
> In general, the approach of the draft is to clearly separate the TCP
> state from the IKE session state. If you look at Section 6, it
> specifically allows for multiple TCP connections between two peers
> even if there is only one IKE SA between them. If one of them becomes
> redundant (because the other peer opened up a new TCP flow for some
> reason), it would make 

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt

[Tommy Pauly]

Hi Daniel,

Thanks for sending this out! Definitely very interesting stuff. I like the new 
focus on how to compress UDP/TCP within Diet-ESP.

Some of the introduction text could use some clarification/wordsmithing:

IPsec/ESP has not been designed to reduce the networking overhead of
   the communications.  In fact saving bandwidth comes with additional
   operation that may affect or impact large infrastructure where
   bandwidth usage is not an issue.  On the other hand, IoT emerged with
   completely different constraints.  IoT communications are different
   in many ways and a few important differences may be that sending any
   extra byte impact significantly the life time of these devices.  In
   addition, these devices are also expected to be sleeping nodes where
   communications are hardly based on sessions as we used to.

Perhaps could be:

IPsec/ESP was not designed to reduce the networking overhead of
   the communications.  In fact, reducing bandwidth often adds computational
   overhead that may negatively impact large infrastructures in which
   bandwidth usage is not a constraint.  On the other hand, IoT devices have
   completely different constraints.  In IoT communications, sending any
   extra bytes can significantly impact the battery life of devices.  These 
devices
   are also often expected to be sleeping nodes, for which IPsec sessions
   have a very different meaning.


I think the work on the appendices to provide more full examples of how the 
packets are compressed is very effective. Thanks for adding that. I did find it 
a bit confusing that the packet diagrams don’t give a clear picture of the 
effect of encryption on inner packet data. In the RFC 4303 diagrams, the 
‘inner’ portions are all summarized as ‘Payload Data’, which is the content 
that is encrypted. In your diagrams, we see the decrypted content written out. 
Perhaps there is some labelling on the figures you can add to make that a bit 
clearer?

Thanks,
Tommy

> On Oct 12, 2016, at 11:50 AM, Daniel Migault  
> wrote:
> 
> Hi, 
> 
> Please find an update version of the diet-esp document we discussed in 
> Berlin. The scope of the compression has been extended, and the compression 
> simplified. We also provided example in the appendix section.
> 
> Comments are welcome as usual!
> 
> BR, 
> Daniel
> 
> -Ursprüngliche Nachricht-
> Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> Gesendet: Mittwoch, 12. Oktober 2016 19:45
> An: Carsten Bormann ; Daniel Migault 
> ; Tobias Guggemos 
> Betreff: New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt
> 
> 
> A new version of I-D, draft-mglt-ipsecme-diet-esp-02.txt
> has been successfully submitted by Daniel Migault and posted to the IETF 
> repository.
> 
> Name: draft-mglt-ipsecme-diet-esp
> Revision: 02
> Title:ESP Header Compression and Diet-ESP
> Document date:2016-10-04
> Group:Individual Submission
> Pages:43
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-02.txt
> Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
> Htmlized:   https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-02
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-diet-esp-02
> 
> Abstract:
>   ESP Header Compression (EHC) defines a flexible framework to compress
>   communications protected with IPsec/ESP.  Compression and
>   decompression is defined by EHC Rules orchestrated by EHC Strategies.
> 
>   The document specifies the Diet-ESP EHC Strategy and associated EHC
>   Rules.  Diet-ESP compresses up to 32 bytes per packet for traditional
>   IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP
>   session.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

[Paul Wouters]

On Mon, 17 Oct 2016, Yoav Nir wrote:


I’m not entirely comfortable with calling something a MUST NOT when all we have 
is conjecture,


It's a little more than conjecture.

1) It has been proven that malicious 1024 bit DH values can be generated
   by academia that cannot be independantly discovered. Therefore any
   nationstate with access to the same theory and more CPU power could
   have done this years ago.

2) We have the RFC 5114 values who'se original authors/sponsors are not
   disclosing how these were generated.

1) + 2) means we cannot know if these values were trapdoor'ed.

If BBN/NIST/NSA wants to share how they seeded these values, we can all
publicly decide if we can keep using these or not. Without such
information, it just becomes an unnecessary risk to take.

Adding Steve Kent, co-author of RFC-5114, to the CC: so that he has
the opportunity to share what he knows about the origins of these
values and their seeds.


 but I have no love and no need of those DH groups.
I don’t believe anyone else depends on these groups (at least in IPsec), so I’m 
fine with such a change.


Thanks,

Paul


Yoav

  On 17 Oct 2016, at 18:54, Daniel Migault  
wrote:

In fact is there anyone opposing their status becomes MUST NOT in rfc4307bis.

On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson  
wrote:
  > I'm proposing it is time to change this to MUST NOT for 4307bis.



  +1

  On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
   wrote:

  >
  >Released a few days ago:
  >
  >       http://eprint.iacr.org/2016/961
  >
  >       A kilobit hidden SNFS discrete logarithm computation
  >       Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel 
Thomé
  >
  >       We perform a special number field sieve discrete logarithm
  >       computation in a 1024-bit prime field. To our knowledge, this
  >       is the first kilobit-sized discrete logarithm computation ever
  >       reported for prime fields. This computation took a little over
  >       two months of calendar time on an academic cluster using the
  >       open-source CADO-NFS software.
  >
  >Basically, this paper shows how to make a DH group of 1024 modp
  >with a backdoor, in two months of academic computing resources,
  >
  >The paper mentions 5114 a few times:
  >
  >       RFC 5114 [33] specifies a number of groups for use with
  >       Diffie-Hellman, and states that the parameters were drawn
  >       from NIST test data, but neither the NIST test data [39] nor
  >       RFC 5114 itself contain the seeds used to generate the finite
  >       field parameters
  >
  >And concludes:
  >
  >       Both from this perspective, and from our more modern one, 
dismissing the
  >       risk of trapdoored primes in real usage appears to have been a 
mistake,
  >       as the apparent difficulties encountered by the trapdoor designer 
in
  >1992
  >       turn out to be easily circumvented. A more conservative design 
decision
  >       for FIPS 186 would have required mandatory seed publication 
instead of
  >       making it optional.  As a result, there are opaque, standardized
  >1024-bit
  >       and 2048-bit primes in wide use today that cannot be properly 
verified.
  >
  >This is the strongest statement yet that I've seen to not trust any
  >of the RFC-5114 groups.
  >
  >The latest 4307bis document has these groups (22-24) as SHOULD NOT,
  >stating:
  >
  >       Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and
  >       2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup
  >       have small subgroups, which means that checks specified in the
  >       "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section
  >       2.2 first bullet point MUST be done when these groups are used.
  >       These groups are also not safe-primes.  The seeds for these groups
  >       have not been publicly released, resulting in reduced trust in
  >       these groups.  These groups were proposed as alternatives for
  >       group 2 and 14 but never saw wide deployment.  It is expected
  >       in the near future to be further downgraded to MUST NOT.
  >
  >I'm proposing it is time to change this to MUST NOT for 4307bis.
  >
  >Possibly, we should do this via SAAG in general, and then follow SAAG's
  >advise in IPSECME.
  >
  >Is there _any_ reason why group 22-24 should not be MUST NOT ?
  >
  >Paul
  >
  >___
  >IPsec mailing list
  >IPsec@ietf.org
  >https://www.ietf.org/mailman/listinfo/ipsec

___
saag mailing list

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

[Yoav Nir]

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.

I don’t believe anyone else depends on these groups (at least in IPsec), so I’m 
fine with such a change.

Yoav

> On 17 Oct 2016, at 18:54, Daniel Migault  wrote:
> 
> In fact is there anyone opposing their status becomes MUST NOT in rfc4307bis.
> 
> On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson  > wrote:
> > I'm proposing it is time to change this to MUST NOT for 4307bis.
> 
> 
> 
> +1
> 
> On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
>  on behalf of 
> p...@nohats.ca > wrote:
> 
> >
> >Released a few days ago:
> >
> >   http://eprint.iacr.org/2016/961 
> >
> >   A kilobit hidden SNFS discrete logarithm computation
> >   Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel Thomé
> >
> >   We perform a special number field sieve discrete logarithm
> >   computation in a 1024-bit prime field. To our knowledge, this
> >   is the first kilobit-sized discrete logarithm computation ever
> >   reported for prime fields. This computation took a little over
> >   two months of calendar time on an academic cluster using the
> >   open-source CADO-NFS software.
> >
> >Basically, this paper shows how to make a DH group of 1024 modp
> >with a backdoor, in two months of academic computing resources,
> >
> >The paper mentions 5114 a few times:
> >
> >   RFC 5114 [33] specifies a number of groups for use with
> >   Diffie-Hellman, and states that the parameters were drawn
> >   from NIST test data, but neither the NIST test data [39] nor
> >   RFC 5114 itself contain the seeds used to generate the finite
> >   field parameters
> >
> >And concludes:
> >
> >   Both from this perspective, and from our more modern one, dismissing 
> > the
> >   risk of trapdoored primes in real usage appears to have been a 
> > mistake,
> >   as the apparent difficulties encountered by the trapdoor designer in
> >1992
> >   turn out to be easily circumvented. A more conservative design 
> > decision
> >   for FIPS 186 would have required mandatory seed publication instead of
> >   making it optional.  As a result, there are opaque, standardized
> >1024-bit
> >   and 2048-bit primes in wide use today that cannot be properly 
> > verified.
> >
> >This is the strongest statement yet that I've seen to not trust any
> >of the RFC-5114 groups.
> >
> >The latest 4307bis document has these groups (22-24) as SHOULD NOT,
> >stating:
> >
> >   Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and
> >   2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup
> >   have small subgroups, which means that checks specified in the
> >   "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section
> >   2.2 first bullet point MUST be done when these groups are used.
> >   These groups are also not safe-primes.  The seeds for these groups
> >   have not been publicly released, resulting in reduced trust in
> >   these groups.  These groups were proposed as alternatives for
> >   group 2 and 14 but never saw wide deployment.  It is expected
> >   in the near future to be further downgraded to MUST NOT.
> >
> >I'm proposing it is time to change this to MUST NOT for 4307bis.
> >
> >Possibly, we should do this via SAAG in general, and then follow SAAG's
> >advise in IPSECME.
> >
> >Is there _any_ reason why group 22-24 should not be MUST NOT ?
> >
> >Paul
> >
> >___
> >IPsec mailing list
> >IPsec@ietf.org 
> >https://www.ietf.org/mailman/listinfo/ipsec 
> >
> 
> ___
> saag mailing list
> s...@ietf.org 
> https://www.ietf.org/mailman/listinfo/saag 
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

[Daniel Migault]

In fact is there anyone opposing their status becomes MUST NOT in
rfc4307bis.

On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson 
wrote:

> > I'm proposing it is time to change this to MUST NOT for 4307bis.
>
>
>
> +1
>
> On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
>  wrote:
>
> >
> >Released a few days ago:
> >
> >   http://eprint.iacr.org/2016/961
> >
> >   A kilobit hidden SNFS discrete logarithm computation
> >   Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel
> Thomé
> >
> >   We perform a special number field sieve discrete logarithm
> >   computation in a 1024-bit prime field. To our knowledge, this
> >   is the first kilobit-sized discrete logarithm computation ever
> >   reported for prime fields. This computation took a little over
> >   two months of calendar time on an academic cluster using the
> >   open-source CADO-NFS software.
> >
> >Basically, this paper shows how to make a DH group of 1024 modp
> >with a backdoor, in two months of academic computing resources,
> >
> >The paper mentions 5114 a few times:
> >
> >   RFC 5114 [33] specifies a number of groups for use with
> >   Diffie-Hellman, and states that the parameters were drawn
> >   from NIST test data, but neither the NIST test data [39] nor
> >   RFC 5114 itself contain the seeds used to generate the finite
> >   field parameters
> >
> >And concludes:
> >
> >   Both from this perspective, and from our more modern one,
> dismissing the
> >   risk of trapdoored primes in real usage appears to have been a
> mistake,
> >   as the apparent difficulties encountered by the trapdoor designer
> in
> >1992
> >   turn out to be easily circumvented. A more conservative design
> decision
> >   for FIPS 186 would have required mandatory seed publication
> instead of
> >   making it optional.  As a result, there are opaque, standardized
> >1024-bit
> >   and 2048-bit primes in wide use today that cannot be properly
> verified.
> >
> >This is the strongest statement yet that I've seen to not trust any
> >of the RFC-5114 groups.
> >
> >The latest 4307bis document has these groups (22-24) as SHOULD NOT,
> >stating:
> >
> >   Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and
> >   2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup
> >   have small subgroups, which means that checks specified in the
> >   "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section
> >   2.2 first bullet point MUST be done when these groups are used.
> >   These groups are also not safe-primes.  The seeds for these groups
> >   have not been publicly released, resulting in reduced trust in
> >   these groups.  These groups were proposed as alternatives for
> >   group 2 and 14 but never saw wide deployment.  It is expected
> >   in the near future to be further downgraded to MUST NOT.
> >
> >I'm proposing it is time to change this to MUST NOT for 4307bis.
> >
> >Possibly, we should do this via SAAG in general, and then follow SAAG's
> >advise in IPSECME.
> >
> >Is there _any_ reason why group 22-24 should not be MUST NOT ?
> >
> >Paul
> >
> >___
> >IPsec mailing list
> >IPsec@ietf.org
> >https://www.ietf.org/mailman/listinfo/ipsec
>
> ___
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] trapdoor'ed DH (and RFC-5114 again)

[John Mattsson]

> I'm proposing it is time to change this to MUST NOT for 4307bis.



+1 

On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
 wrote:

>
>Released a few days ago:
>
>   http://eprint.iacr.org/2016/961
>
>   A kilobit hidden SNFS discrete logarithm computation
>   Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel Thomé
>
>   We perform a special number field sieve discrete logarithm
>   computation in a 1024-bit prime field. To our knowledge, this
>   is the first kilobit-sized discrete logarithm computation ever
>   reported for prime fields. This computation took a little over
>   two months of calendar time on an academic cluster using the
>   open-source CADO-NFS software.
>
>Basically, this paper shows how to make a DH group of 1024 modp
>with a backdoor, in two months of academic computing resources,
>
>The paper mentions 5114 a few times:
>
>   RFC 5114 [33] specifies a number of groups for use with
>   Diffie-Hellman, and states that the parameters were drawn
>   from NIST test data, but neither the NIST test data [39] nor
>   RFC 5114 itself contain the seeds used to generate the finite
>   field parameters
>
>And concludes:
>
>   Both from this perspective, and from our more modern one, dismissing the
>   risk of trapdoored primes in real usage appears to have been a mistake,
>   as the apparent difficulties encountered by the trapdoor designer in
>1992
>   turn out to be easily circumvented. A more conservative design decision
>   for FIPS 186 would have required mandatory seed publication instead of
>   making it optional.  As a result, there are opaque, standardized
>1024-bit
>   and 2048-bit primes in wide use today that cannot be properly verified.
>
>This is the strongest statement yet that I've seen to not trust any
>of the RFC-5114 groups.
>
>The latest 4307bis document has these groups (22-24) as SHOULD NOT,
>stating:
>
>   Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and
>   2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup
>   have small subgroups, which means that checks specified in the
>   "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section
>   2.2 first bullet point MUST be done when these groups are used.
>   These groups are also not safe-primes.  The seeds for these groups
>   have not been publicly released, resulting in reduced trust in
>   these groups.  These groups were proposed as alternatives for
>   group 2 and 14 but never saw wide deployment.  It is expected
>   in the near future to be further downgraded to MUST NOT.
>
>I'm proposing it is time to change this to MUST NOT for 4307bis.
>
>Possibly, we should do this via SAAG in general, and then follow SAAG's
>advise in IPSECME.
>
>Is there _any_ reason why group 22-24 should not be MUST NOT ?
>
>Paul
>
>___
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec