Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-ipv6-ipv4-codes-05

[Alissa Cooper]

Robert, thanks for your review. I entered a No Objection ballot.

Alissa

> On Nov 14, 2020, at 4:32 PM, Robert Sparks via Datatracker  
> wrote:
> 
> Reviewer: Robert Sparks
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-ipv6-ipv4-codes-05
> Reviewer: Robert Sparks
> Review Date: 2020-11-14
> IETF LC End Date: 2020-12-01
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready for publication as a Proposed Standard RFC
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09

[Alissa Cooper]

Christer, thanks for your review. Valery, thanks for your responses. I entered 
a No Objection ballot.

Alissa


> On Dec 13, 2019, at 3:17 PM, Christer Holmberg via Datatracker 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-qr-ikev2-09
> Reviewer: Christer Holmberg
> Review Date: 2019-12-13
> IETF LC End Date: 2019-12-25
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is well-written, and almost ready for publication.
> However, I have a couple of minor comments that I would like the authors to
> address.
> 
> Major issues: None
> 
> Minor issues:
> 
> Q1:
> 
> The Security Considerations lists IKEv2/IPSec algorithms that are not
> considered quantum-resistant. However, that is not mentioned anywhere else. I
> think it would be good to mention that in the Abstract and/or Introduction.
> 
> Q2:
> 
> Section 3 says:
> 
>   "If the responder does not support this specification or does not have
>   any PPK configured, then it ignores the received notification and
>   continues with the IKEv2 protocol as normal."
> 
> I assume the ignoring of a non-supported notification and continuing with
> normal IKEv2 is part of the IKEv2 specification. If so, I suggest to say add
> something like:
> 
> ", as described in RFC."
> 
> Nits/editorial comments:
> 
> Q3:
> 
> The Security Considerations talk about the Grover's algorithm. Please add a
> reference.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
draft-ietf-ipsecme-qr-ikev2-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/



--
COMMENT:
--

I think this document should formally update RFC 7296. Was that discussed in
the WG?

I think the citation for [NISTPQCFP] should link to the actual call for
proposals.

Section 6:

"In addition, the policy SHOULD be set to negotiate only quantum-
   resistant symmetric algorithms; while this RFC doesn't claim to give
   advice as to what algorithms are secure (as that may change based on
   future cryptographical results), below is a list of defined IKEv2 and
   IPsec algorithms that should not be used, as they are known to
   provide less than 128 bits of post-quantum security"

This paragraph mixes normative SHOULD with non-normative "should not" in the
same paragraph. I was wondering if that is intentional.


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

Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-implicit-iv-07

[Alissa Cooper]

Joel, thanks for your review. I entered a No Objection ballot.

Alissa


> On Sep 27, 2019, at 2:31 PM, Joel Halpern via Datatracker  
> wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-implicit-iv-07
> Reviewer: Joel Halpern
> Review Date: 2019-09-27
> IETF LC End Date: 2019-10-07
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: THis document is ready for publication as a Proposed Standard
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments: N/A
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

[Alissa Cooper]

> On Nov 21, 2018, at 1:03 AM, Paul Wouters  wrote:
> 
> On Mon, 19 Nov 2018, Alissa Cooper wrote:
> 
>> --
>> COMMENT:
>> --
>> 
>> Section 5:
>> 
>> "Enterprise Certificate Agency" --> I would have expected this to say
>> Enterprise Certificate Authority.
> 
> Your expectation is correct :) I will fix.
> 
>> "Other generic or public domains, such as top-level domains, similarly SHOULD
>> NOT be whitelisted." Under what exceptional circumstances would it make sense
>> to whitelist a TLD? Is this like if I run Example Corp and I own .example?
> 
> Exactly. Or if you would use .internal or if Warren gets his way .alt :)

Thanks. It might be worth giving an example or two in the document.

Alissa

> 
> Paul

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

Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-split-dns-12

[Alissa Cooper]

Christer, thank you for your review. Tommy, thank you for addressing Christer’s 
comments. I entered a No Objection ballot.

Alissa


> On Oct 22, 2018, at 4:26 PM, Tommy Pauly  wrote:
> 
> Hi Christer,
> 
> Thanks again for the review. I've addressed all three comments below in an 
> update to the draft:
> 
> https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13 
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-13.txt 
> 
> 
> Thanks,
> Tommy 
> 
>> On Aug 19, 2018, at 1:39 PM, Christer Holmberg 
>> mailto:christer.holmb...@ericsson.com>> 
>> wrote:
>> 
>> Hi Tommy,
>> 
>> Please see inline.
>> 
>> 
>> Minor issues:
>> 
>> Q1:
>> 
 Section 3.1 contains some SHOULD-do statements, e.g.,:
 
 "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and
 INTERNAL_IP6_DNS attributes in the CFG_REQUEST"
 
 "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN 
 attributes
 in the CFG_REQUEST."
 
 Is there a reason for not using MUST instead of SHOULD?
>>> 
>>> In general, the CFG_REQUEST attributes are a bit loose—they're hints more 
>>> than requirements.
>>> 
>>> From section 3.15.1 of RFC7296:
>>> 
>>>  The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
>>>  information from its peer.  If an attribute in the CFG_REQUEST
>>>  Configuration payload is not zero-length, it is taken as a suggestion
>>>  for that attribute.  The CFG_REPLY Configuration payload MAY return
>>>  that value, or a new one.  It MAY also add new attributes and not
>>>  include some requested ones.  Unrecognized or unsupported attributes
>>>  MUST be ignored in both requests and responses.
>>> 
>>> So, the CFG_REPLY MUST have a DNS server to go along with the DNS domain, 
>>> but I left the SHOULD in spirit 
>>> of the fact that the CFG_REQUEST is more of a suggestion.
>>> 
>>> That being said, if others in the WG would like to see this be a MUST, I'm 
>>> fine with that as well. I don't think we 
>>> should have the responder error out if it doesn't see both, however.
>> 
>> Well, if it is only a suggestion, then I guess my question is why use 
>> something as strong as SHOULD :) SHOULD basically means 
>> MUST-unless-you-have-a-good-reason to.
>> 
>> In general, is providing suggestions a SHOULD, or is it only for the 
>> attributes above?
>> 
>> Anyway, if you want to have a SHOULD (or even a MUST) I won't object. But, 
>> when I see a SHOULD, I always ask about the background :)
>> 
>> 
>> Q2:
>> 
 Section 3.2 says:
 
 "the initiator SHOULD behave as if Split DNS configurations are not 
 supported
 by the server."
 
 Again, is there a reason for not using MUST?
>>> 
>>> This one could be a MUST. The one exception I could see is if the initiator 
>>> was statically configured with some split DNS domains to use as split 
>>> domains
>>> In case the responder didn't provide any in the CFG_REPLY, it should still 
>>> use those and not send all DNS queries inside the tunnel. I wouldn't want 
>>> this
>>> MUST to disable the static configuration workarounds that implementations 
>>> have done prior to allowing split DNS to be negotiated.
>> 
>> Could you say:
>> 
>> "the initiator MUST behave as if a Split DNS configurations are not 
>> supported, unless > above>"
>> 
>> 
>> 
>> Nits/editorial comments:
>> 
>> Q3:
>> 
 Is there a need for the "Background" section? Since the text is related to 
 what
 is described in the "Introduction", could the the text be moved there?
>>> 
>>> The main new points that the Background section adds on top of the 
>>> Introduction are:
>>> - The prior art for split DNS in IKEv1
>>> - The fact that this is currently mainly seen in enterprise VPN deployments
>>> 
>>> These points could indeed be moved to the introduction. I had felt they fit 
>>> better as "background" since they're 
>>> not essential to the description of the protocol, but give context that is 
>>> relevant now (and may be less so in the future).
>> 
>> The first sections of both the Introduction and the Background sections talk 
>> about split DNS:
>> 
>>   "Split DNS is a common configuration for secure tunnels, such as
>>   Virtual Private Networks in which host machines private to an
>>   organization can only be resolved using internal DNS resolvers"
>> 
>>   "Split DNS is a common configuration for enterprise VPN deployments,
>>   in which one or more private DNS domains are only accessible and
>>   resolvable via an IPsec based VPN connection."
>> 
>> So, isn't Split DNS already covered by the Introduction? What extra does the 
>> Background text bring?
>> 
>> The second paragraph of the Background could be placed at the end of the 
>> Introduction, in my opinion.
>> 
>> Regards,
>> 
>> Christer
>> 
>> ___
>> IPsec 

[IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
charter-ietf-ipsecme-11-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ipsecme/



--
COMMENT:
--

Substantive comments:

(1) I don't see the value in having an expiration date in a WG charter because
it's not enforced in practice. The previous version of this charter said the WG
would close if the charter wasn't updated by Dec 2017, but the WG continued to
exist without the charter being updated. This charter seems tightly scoped
enough to just get the work done according to the milestone dates or close
sooner if people lose interest.

(2) I think it might be worth a few words to state the reason why the goal was
for the new IKEv2 mode to have the same quantum resistant properties as existed
in IKEv1, rather than better/fuller quantum resistance.

Nits:

Based on the number of grammar and wording errors I found in this charter, I
would strongly suggest doing a clean-up pass to make sure all of the text reads
properly. Here is what I found:

(1)
s/to have similar quantum resistant properties than IKEv1 had/to have similar
quantum resistant properties that IKEv1 had/

(2)
s/in form of counter/in the form of a counter/

(3)
I can't parse this sentence:

"A growing number of use cases for constrained network - but not
limited to - have shown interest in reducing ESP (resp. IKEv2)
overhead by compressing ESP (resp IKEv2) fields."

(4)
OLD
Currently IKE peers have no explicit way
to indicate each other which signature format(s) the support, that
leads to ineroperability problems.

NEW
Currently IKE peers have no explicit way
to indicate to each other which signature format(s) they support. That
leads to ineroperability problems.

(5) The milestones need to be updated. Some of the dates and draft names are
wrong.


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

Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-eddsa-04

[Alissa Cooper]

Christer, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Nov 18, 2017, at 2:59 AM, Christer Holmberg 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-eddsa-04
> Reviewer: Christer Holmberg
> Review Date: 2017-11-17
> IETF LC End Date: 2017-12-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is well written, and almost ready for publication.
> However, I have some editorial change suggestions that I think would improve
> the readability of the document.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> Q1:
> 
> 
> In the Abstract the text says " Edwards-curve digital signature algorithm",
> without the EdDSA abbreviation, and in the Introduction the text says "EdDSA"
> without the enhancement.
> 
> I suggest to say "Edwards-curve digital signature algorithm (EdDSA)" in the
> first occurrences within the Abstract and the Introduction.
> 
> Q2:
> 
> 
> In the Introduction the text says "The latter RFC" and "that document". I
> suggest to explicitly use the RFC numbers instead.
> 
> That makes it easier to read, and there is always a theoretical change that
> someone files an errata, or update the text within another RFC, that changes
> the order to the RFCs so that "The latter" etc points to the wrong RFC...
> 
> Q3:
> 
> 
> In the Introduction the text says:
> 
>   "EdDSA defines the binary format of the signatures that should be used
>   in the "Signature Value" field of the Authentication Data Format in
>   section 3."
> 
> Section 3 of what? I assume you refer section 3 of RFC 8032, so I suggest to
> explicitly say that. Otherwise someone (at least I did) may jump to section 3
> of the draft and start looking.
> 
> The same thing applies to "Appendix A". Please indicate the RFC number.
> 
> Q4:
> 
> 
> In the Introduction the text says:
> 
> "we define a new value"
> 
> I suggest to say "this document defines a new value".
> 
> Or, you could even say "section 2 of this document defines a new value".
> 
> Q5:
> 
> 
> In section 3, I suggest to add a reference (URL?) to the hash algorithm
> registry.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/



--
COMMENT:
--

"A typical Initiator or
   bot-net member in 2014 can perform slightly less than a million
   hashes per second per core"

Is this supposed to say 2014? Struck me as a little weird.


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

[IPsec] Alissa Cooper's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-ipsecme-chacha20-poly1305-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/



--
COMMENT:
--

Agree with the comments about toning down the language in the first
paragraph.


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