Subject: [saag] ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

From: Scott Mansfield <[email-masked]>
Date: Fri, 7 Jun 2013 09:22:22 +0000

https://datatracker.ietf.org/liaison/1255/

Further information on this document.  X.1037 is in an ITU approval process called AAP.  The deadline for comments on the document is 12 June 2013.  There are a number of comments on the document already submitted by an ITU sector member, so the document will have to be reviewed and modified before it can move forward.  The next step in the process would be something call additional review.  In additional review, comments are accepted only on the parts of the document that were modified, no new substantive comments on the rest of the document are accepted.  So, if there are comments anyone would like to make on the document, please send them to be before 12 June.

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Jun 2013 12:23:14 +0100

Hi Scott,

> Further information on this document.  X.1037 is in an ITU approval process called AAP.  The deadline for comments on the document is 12 June 2013.  There are a number of comments on the document a…

First, thanks for sending this to the list. I think that's a
more effective way to get stuff looked at compared to waiting
for the SEC ADs to get on the case:-) If someone has comments
then replying in this thread is probably the right thing.

On the document itself, I only have a meta-comment, feel free
to edit the wording however you'd like but my suggestion is
that they include a bit of extra text in either the summary or
section 1 "scope" along the following lines:

"This recommendation considers the security aspects of IPv6
which is standardised by the IETF. As can be seen from the
text below, IETF standards evolve over time as new RFCs are
produced, so before applying suggested mitigating measures,
readers should check for more recent work on relevant IETF
specifications. For security related questions, one way to
do that is to send an email to the IETF's security area
mailing list: [email-masked]. Another is to send a mail to
the IETF's general discussion list: [email-masked]."

The reason to suggest that is that we've seen a number of
comments on previous liaisons along the lines of "yeah that
used to be a problem but RFCxxx has fixed that or draft-foo
is fixing that" or "your suggested mitigation is counter
to RFCyyy or draft-bar" and a pointer like the above might
lessen folks concerns about ITU_T text resulting in bad
outcomes.

If you think my comment would set off some kind of SDO turf
war then I'm ok that we not make it a formal liaison response.

Cheers,
S.

> Regards,
> -scott.
> 
> Scott Mansfield
> Ericsson Inc.
> +1 724 931 9316
> 
> 
> 
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Scott Mansfield <[email-masked]>
Date: Fri, 7 Jun 2013 12:09:02 +0000

We have four options and it really is up to you....  We can send your comment as a liaison response, we can submit your comment as a LC comment to the document itself, we could do both, or neither.

My opinion is that we don't necessarily want to open the door that a reference to an IETF RFC is going to remain forward-compatible in perpetuity.  When an ITU-T recommendation references a document, it references a specific version of that document.  I think it would be important to require a rev of the recommendation if a newer IETF document is to be referenced.

I do like the first sentence and is something that always bears repeating.

Just my two cents. 

Regards,
-scott.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Friday, June 07, 2013 7:23 AM
To: Scott Mansfield
Cc: [email-masked]
Subject: Re: [saag] ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

Hi Scott,

> Further information on this document.  X.1037 is in an ITU approval process called AAP.  The deadline for comments on the document is 12 June 2013.  There are a number of comments on the document a…

First, thanks for sending this to the list. I think that's a more effective way to get stuff looked at compared to waiting for the SEC ADs to get on the case:-) If someone has comments then replying in this thread is probably the right thing.

On the document itself, I only have a meta-comment, feel free to edit the wording however you'd like but my suggestion is that they include a bit of extra text in either the summary or section 1 "scope" along the following lines:

"This recommendation considers the security aspects of IPv6 which is standardised by the IETF. As can be seen from the text below, IETF standards evolve over time as new RFCs are produced, so before applying suggested mitigating measures, readers should check for more recent work on relevant IETF specifications. For security related questions, one way to do that is to send an email to the IETF's security area mailing list: [email-masked]. Another is to send a mail to the IETF's general discussion list: [email-masked]."

The reason to suggest that is that we've seen a number of comments on previous liaisons along the lines of "yeah that used to be a problem but RFCxxx has fixed that or draft-foo is fixing that" or "your suggested mitigation is counter to RFCyyy or draft-bar" and a pointer like the above might lessen folks concerns about ITU_T text resulting in bad outcomes.

If you think my comment would set off some kind of SDO turf war then I'm ok that we not make it a formal liaison response.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Jun 2013 13:35:21 +0100

Hi Scott,

On 06/07/2013 01:09 PM, Scott Mansfield wrote:
> 
> We have four options and it really is up to you....  We can send your
> comment as a liaison response, we can submit your comment as a LC
> comment to the document itself, we could do both, or neither.

I'm happy to let you choose which is most useful. (Incl. the "neither"
option if you think that best.) Not knowing about how they process
stuff, I'd say this is maybe more of a "LC comment" type thing.

> My opinion is that we don't necessarily want to open the door that a
> reference to an IETF RFC is going to remain forward-compatible in
> perpetuity. When an ITU-T recommendation references a document, it
> references a specific version of that document.  I think it would be
> important to require a rev of the recommendation if a newer IETF
> document is to be referenced.

Fair point. If you do use my text then maybe:

OLD:

  As can be seen from the text below, IETF standards evolve over time
  as new RFCs are produced...

NEW:

  As can be seen from the text below, Internet technologies evolve
  over time and new RFCs are produced reflecting that evolution...

But you should also feel free to edit the text any way you like
that gets the message over. (Or not send it at all.)

> I do like the first sentence and is something that always bears

Yep:-)

> Just my two cents.

Thanks,
S.

> 
> Regards, -scott.
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Friday, June 07, 2013 7:23
> AM To: Scott Mansfield Cc: [email-masked] Subject: Re: [saag] ITU-T
> Recommendation ITU-T X.1037, Technical security guideline on
> deploying IPv6
> 
> 
> Hi Scott,
> 
>> Further information on this document.  X.1037 is in an ITU approval
>> process called AAP.  The deadline for comments on the document is
>> 12 June 2013.  There are a number of comments on the document
>> already submitted by an ITU sector member, so the document will
>> have to be reviewed and modified before it can move forward.  The
>> next step in the process would be something call additional review.
>> In additional review, comments are accepted only on the parts of
>> the document that were modified, no new substantive comments on the
>> rest of the document are accepted.  So, if there are comments
>> anyone would like to make on the document, please send them to be
>> before 12 June.
> 
> First, thanks for sending this to the list. I think that's a more
> effective way to get stuff looked at compared to waiting for the SEC
> ADs to get on the case:-) If someone has comments then replying in
> this thread is probably the right thing.
> 
> On the document itself, I only have a meta-comment, feel free to edit
> the wording however you'd like but my suggestion is that they include
> a bit of extra text in either the summary or section 1 "scope" along
> the following lines:
> 
> "This recommendation considers the security aspects of IPv6 which is
> standardised by the IETF. As can be seen from the text below, IETF
> standards evolve over time as new RFCs are produced, so before
> applying suggested mitigating measures, readers should check for more
> recent work on relevant IETF specifications. For security related
> questions, one way to do that is to send an email to the IETF's
> security area mailing list: [email-masked]. Another is to send a mail
> to the IETF's general discussion list: [email-masked]."
> 
> The reason to suggest that is that we've seen a number of comments on
> previous liaisons along the lines of "yeah that used to be a problem
> but RFCxxx has fixed that or draft-foo is fixing that" or "your
> suggested mitigation is counter to RFCyyy or draft-bar" and a pointer
> like the above might lessen folks concerns about ITU_T text resulting
> in bad outcomes.
> 
> If you think my comment would set off some kind of SDO turf war then
> I'm ok that we not make it a formal liaison response.
> 
> Cheers, S.
> 
> 
>> Regards, -scott.
>> 
>> Scott Mansfield Ericsson Inc. +1 724 931 9316
>> 
>> 
>> 
>> 
>> _______________________________________________ saag mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/saag
>> 
> 
>

---

From: SM <[email-masked]>
Date: Fri, 07 Jun 2013 07:59:20 -0700

Hi Scott,
>document is to be referenced.

References being subject to revision is mentioned in Section 2 of 
"Technical security guideline on deploying IPv6".  I would go with 
the text suggested by Stephen Farrell and use "published" to follow 
the ITU line.

Measure 5 (Page 9) mentions RFC 3627.  The guidance in RFC 6164 
supercedes what is in RFC 3627.  RFC 3627 is Historic (see RFC 
6547).  I suggest removing the following sentence:

   "Even though [IETF RFC3627]declares that /127 prefix on a point-to-point
    link is illegal, [IETF RFC6164] permits to use /127 prefix under certain
    conditions."

Regards,
-sm