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

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

From: Scott Mansfield
Sent: Friday, June 07, 2013 5:22 AM
To: [email-masked]'
Subject: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

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: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Jun 2013 17:03:03 +1200

Scott,

Has the Security Area actually reviewed this document? If not,
IMHO they certainly need to, PDQ.

A few things that caught my eye in a very quick scan:

> 7.3.1 Security threats and countermeasures

> Threat 7: A Network Address Translation (NAT) device is
> commonly deployed on a border of a network and translates
> either source or destination IP addresses of a packet in
> order to bridge two different types of networks such as
> private-global networks and IPv4-IPv6 networks. Particularly,
> NAT66, so-called NAT and port translation version 6 (NPTv6),
> translates IP addresses of packets between two distinct IPv6
> networks

That is wrong. The IETF has not defined NAT66. A correct
statement would be:

   IPv6-to-IPv6 Network Prefix Translation (NPTv6) translates
   the prefixes of the addresses of packets between two
   distinct IPv6 networks, but does not translate the interface
   identifiers and port numbers. This is an Experimental
   protocol, not on the standards track.

(the reference is RFC 6296)

Aside: if this is typical of the document's thoroughness and
accuracy, that is rather worrying.

> Measure 7: IETF is discussing stateless NAT66 (without a 
> state table) function.

As far as I know this is an untrue statement.

> Measure 8: To minimize the security risk by forged RA 
> messages, it is recommended that each host discard all RA 
> messages with an extremely short lifetime.

"Extremely short" isn't actionable. (Also, Measure 10 seems more
to the point.)

> Measure 18: IDSs have to support the decapsulation function 
> of the encapsulated IPv6 packets and 6to4 packets over 6to4.

Why is this limited to 6to4 tunnels? Any form of IPv6-in-IPv4
tunnel has this risk. There are other risks specific to tunnels,
e.g. RFC 6324.

There are also many other security issues with 6to4 (RFC 3964)
and a number of guidelines about how to deploy it and how *not*
to deploy it (RFC 6343).

There are relevant documents that are listed in the references
but are not mentioned in the text - surely the important points
in them should be mentioned? At the moment, the document is an
incomplete story, and a reader might be confused into thinking
it covers everything there is to know.

In general I was surprised how short this document is. For
example,there is absolutely no discussion of scanning attacks,
DoS, or of the very real problems that firewalls face in
handling legitimate IPv6 extension headers at line speed.
Serious efforts such as Fernando Gont's are hundreds of pages long.

I'm no security expert, so again: it needs a serious review by
somebody who is one.

Regards
   Brian Carpenter

On 08/06/2013 00:00, Scott Mansfield wrote:
> 
> From: Scott Mansfield Sent: Friday, June 07, 2013 5:22 AM To:
>  [email-masked]' Subject: ITU-T Recommendation ITU-T X.1037, 
> Technical security guideline on deploying IPv6
> 
> 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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> _______________________________________________ v6ops mailing
>  list [email-masked] 
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Scott Mansfield <[email-masked]>
Date: Fri, 7 Jun 2013 14:25:35 +0000

Here is the link to the document
https://datatracker.ietf.org/documents/LIAISON/liaison-2013-05-07-itu-t-sg-17-sec-lso-on-the-itu-t-recommendation-itu-t-x1037-technical-security-guideline-on-deploying-ipv6-to-ietf-security-are-attachment-1.pdf

regards,
-scott.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Friday, June 07, 2013 10:13 AM
To: Scott Mansfield
Cc: [email-masked]
Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

Can anyone provide the url for the actual document?

Thanks!
Fernando
On Jun 7, 2013 2:14 PM, "Scott Mansfield" <[email-masked]<mailto:[email-masked]>> wrote:

From: Scott Mansfield
Sent: Friday, June 07, 2013 5:22 AM
To: [email-masked]<mailto:[email-masked]>'
Subject: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316<tel:%2B1%20724%20931%209316>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 04:20:36 +0200

> IMHO they certainly need to, PDQ.

FWIW, I was meaning to review this document (as an individual), but it
was unclear how we were supposed to do such reviews.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tim Chown <[email-masked]>
Date: Sun, 9 Jun 2013 09:33:11 +0100

I agree with Brian's comments.

I would also add that a document structure that was split into threats that are equivalent to or have a parallel to IPv4 threats, and threats that are IPv6-specific, would be useful to most readers.

Do we know who the authors are, or who is producing the document?

Tim

On 8 Jun 2013, at 06:03, Brian E Carpenter <[email-masked]> wrote:

> [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 Jun 2013 02:15:17 -0700 (PDT)

Here is the Liasion statement from the ITU:

----- Original Message -----
> From: Tim Chown <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; Scott Mansfield <[email-masked]>
> Sent: Sunday, 9 June 2013 6:33 PM
> I would also add that a document structure that was split into threats that are 
> equivalent to or have a parallel to IPv4 threats, and threats that are 
> IPv6-specific, would be useful to most readers.
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 09 Jun 2013 11:21:12 +0100

> I'm no security expert, so again: it needs a serious review by

i had a quick flick through the document and concur.  There are several
howlers other than the ones you pointed out, and the document is clearly
not written by anyone with any real working knowledge of ipv6.

Would there be any value in writing an ID in v6ops to cover this topic more
comprehensively?  I guess it would go out of date very quickly.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 15:09:38 +0200

> comprehensively?  I guess it would go out of date very quickly.

We've doing that in separate documents, and different wgs (6man, opsec,
and v6ops). Most of the documents are based on the large IPv6 security
document I produced some time ago... and then published pieces of such
document as stand-alone documents, so that they would be easier to move
forward.

For example, the one for ND is here:
<http://tools.ietf.org/html/draft-gont-opsec-ipv6-nd-security> -- this
one being the largest.

And others can be found by searching my last name at
<https://www.rfc-editor.org/idsearch.html> an/or at:
<http://tools.ietf.org/id/gont?maxhits=100&key=date&dir=desc>.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 15:59:45 +0200

Scott,

Broad and (possibly) stupid question:

What's the objective of this sort of liason?

For example, the liason
(<https://datatracker.ietf.org/documents/LIAISON/liaison-2013-04-02-itu-t-sg-17-sec-liaison-to-ietf-sec-area-on-the-ipv6-security-guideline-attachment-1.pdf>)
claims that they are aware about all the work of the SEC area regarding
IPv6 security, but I'd argue that most, if not all, such work happens in
the Internet Area, or the O&A Area.

Additionally, if there is no specified way for IETFers to provide
feedback (even if it's eventually disregarded), then why should the IETF
care about what ITU is doing?

Cheers,
Fernando

On 06/07/2013 04:25 PM, Scott Mansfield wrote:
> *From:[email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Fernando 
> Gont *Sent:* Friday, June 07, 2013 10:13 AM *To:* Scott Mansfield 
> *Cc:* [email-masked] *Subject:* Re: [v6ops] FW: ITU-T Recommendation 
> ITU-T X.1037, Technical security guideline on deploying IPv6
> 
> 
> 
> Thanks! Fernando
> On Jun 7, 2013 2:14 PM, "Scott Mansfield" 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> 
> 
> 
> 
> *From:*Scott Mansfield *Sent:* Friday, June 07, 2013 5:22 AM *To:* 
> [email-masked] <mailto:[email-masked]>' *Subject:* ITU-T 
> Recommendation ITU-T X.1037, Technical security guideline on 
> deploying IPv6
> 
> 
> 
> 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
> 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 <tel:%2B1%20724%20931%209316>
> 
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] <mailto:[email-masked]>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 09 Jun 2013 12:44:09 -0400

> Do we know who the authors are, or who is producing the document?
...

ITU-T documents have an assigned editor while they are in process, but 
are modified on the basis of written contributions from any interested 
party. The contributions are reviewed at meetings and the accepted parts 
are folded in by the editor.

As an X-series document, this is being produced by Study Group 17. Last 
Call ends June 12, so Scott has to get the IETF response in before then. 
The editor is Koji Nakao <[email-masked]> and the Rapporteur 
(equivalent to WG Chair) is Patrick Mwe Sigwa <[email-masked]>. You 
can pull all this out of the Study Group 17 page at
http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/Pages/default.aspx.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Jun 2013 19:17:50 +0200

> http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/Pages/default.aspx.

Put another way: Who should we fire our feedback to? All of the above?

Thanks,

---

From: Tom Taylor <[email-masked]>
Date: Sun, 09 Jun 2013 17:19:39 -0400

> Put another way: Who should we fire our feedback to? All of the above?

Very briefly, the formal channel is the liaison Scott has to write up. 
That has to indicate all the points that need fixing, at least in 
summary form, but actual new text is preferred. I'll volunteer to help 
create that document if necessary. The relevant procedural text is:

<quote>

During the last call, should any Member State or Sector Member be of the 
opinion that the draft new or revised Recommendation should not be 
approved, they should advise their reasons for disapproving and indicate 
the possible changes that would facilitate further consideration and 
approval of the draft new or revised Recommendation. TSB will make the 
comments available to the membership of ITU-T.

</quote>

I'm a little rusty, but I think the IETF is considered the equivalent of 
a Sector Member.

Informally you can send E-mails to the Rapporteur and his two 
associates. His Associate Rapporteurs are Dmitry Kostrov 
<[email-masked]> and Heung Ryong Oh <[email-masked]>.

Reconsidering, I think the Rapporteur's last name is Mwesigwa without 
the space.

Tom Taylor

---

From: "Chip Sharp (chsharp)" <[email-masked]>
Date: Sun, 9 Jun 2013 22:34:43 +0000

My $.02,
Sending a liaison at the end of the process, when the SG is about to send a document into the approval process is not indicative of collaboration.
Study Groups should send the liaison when they start the work and with each draft developed.

Also, only ITU-T Members can submit comments during AAP.   So the Rapporteurs are not obligated to consider comments sent to them by non-Members.
ISOC is a Sector Member.

Chip

On Jun 9, 2013, at 11:19 PM, Tom Taylor <[email-masked]>
 wrote:

> Very briefly, the formal channel is the liaison Scott has to write up. That has to indicate all the points that need fixing, at least in summary form, but actual new text is preferred. I'll volunteer to help create that document if necessary. The relevant procedural text is:
> 
> <quote>
> 
> During the last call, should any Member State or Sector Member be of the opinion that the draft new or revised Recommendation should not be approved, they should advise their reasons for disapproving and indicate the possible changes that would facilitate further consideration and approval of the draft new or revised Recommendation. TSB will make the comments available to the membership of ITU-T.
> 
> </quote>
> 
> I'm a little rusty, but I think the IETF is considered the equivalent of a Sector Member.
> 
> Informally you can send E-mails to the Rapporteur and his two associates. His Associate Rapporteurs are Dmitry Kostrov <[email-masked]> and Heung Ryong Oh <[email-masked]>.
> 
> Reconsidering, I think the Rapporteur's last name is Mwesigwa without the space.
> 
> Tom Taylor

---

From: Arturo Servin <[email-masked]>
Date: Sun, 09 Jun 2013 20:44:29 -0300

Nick,

	About IPv6 Security?

	There is one in opsec:

http://tools.ietf.org/html/draft-ietf-opsec-v6-02

/as

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jun 2013 00:45:40 +0200

On 06/10/2013 12:34 AM, Chip Sharp (chsharp) wrote:
> My $.02, Sending a liaison at the end of the process, when the SG is
> about to send a document into the approval process is not indicative
> of collaboration. 

It's hard to collaborate when the rules are not clear. -- At the very
least, I'd have expected that it was straightforward who we were
supposed to send our feedback to, if it was possible to have public
discussion of the feedback, etc

> Also, only ITU-T Members can submit comments during AAP.   So the
> Rapporteurs are not obligated to consider comments sent to them by
> non-Members. ISOC is a Sector Member.

Does that mean that anyone belonging to an ISOC chapter can submit?

Or.. what are the requirements? Are there "ISOC representatives" at ITU?

Cheers,

---

From: "Niall O'Reilly" <[email-masked]>
Date: Mon, 10 Jun 2013 10:50:35 +0100

> ISOC is a Sector Member.

	As are the RIRs, with the apparent exception of LACNIC.

	Niall O'Reilly

---

From: Bill Jouris <[email-masked]>
Date: Mon, 10 Jun 2013 07:13:46 -0700 (PDT)

Let me second Fernando's comments.  

Unless someone would like to suggest a reason why the procedures for collaboration should NOT be shared/public . . . . 

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Sun, 6/9/13, Fernando Gont <[email-masked]> wrote:

From: Fernando Gont <[email-masked]>
Subject: Re: [v6ops] FW:  ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6
To: "Chip Sharp (chsharp)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Scott Mansfield" <[email-masked]>
Date: Sunday, June 9, 2013, 3:45 PM

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jun 2013 17:10:19 +0200

> http://tools.ietf.org/html/draft-ietf-opsec-v6-02

There are *many* in opsec -- all of which the ITU document apparently
ignored.

Cheers,

---

From: Scott Mansfield <[email-masked]>
Date: Mon, 10 Jun 2013 11:03:52 +0000

A couple of things...

1) ISOC is a sector member, therefore they can submit comments.
2) The ITU-T send the document to the IETF for comment.  Therefore, the IETF can either liaise comments.
3) Any individual contributor to the IETF talk to a ISOC to have ISOC submit comments on their behalf -- but then ISOC (obviously) needs to agree with the comments. 
4) Any other ITU-T member can submit comments as well, so If you know a sector member that agrees with your concerns about the liaised document, then the AAP comments can be submitted that way.

Now this is just my opinion....
If you aren't a Sector Member, it would be better to have a sector member submit your comments especially if they can be relied upon to participate in the any review/explanation of the comments.

This is an opportunity to provide input to the ITU-T security work.  The document already has some Last Call comments, so the document has to go through an "additional review", but that process is different than doing another last call as would be done in the IETF.  During Additional Review, only comments on the modified sections of the document are allowed.

Bottom line is, the ITU-T sent a document for review, we can liaise comments that the Sec AD's and WG Chairs agree to, or a Sector member of the ITU-T can submit comments.  We have until Wed Jun 12 to submit AAP comments.

Chip, on your point, I agree that this isn't the best indication of true collaborative work, but it is what we have.  So my suggestion is that if we have anything of substance, we should send in AAP comments from a sector member.

Regards,
-scott.
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Sunday, June 09, 2013 6:46 PM
To: Chip Sharp (chsharp)
Cc: Tom Taylor; [email-masked]; Scott Mansfield
Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

> about to send a document into the approval process is not indicative 

It's hard to collaborate when the rules are not clear. -- At the very least, I'd have expected that it was straightforward who we were supposed to send our feedback to, if it was possible to have public discussion of the feedback, etc

Cheers,

---

From: Scott Mansfield <[email-masked]>
Date: Tue, 11 Jun 2013 13:41:45 +0000

Liaising a list back would be interesting.  If you have a list, I could create a liaison.

Regards,
-scott.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, June 10, 2013 11:10 AM
To: Arturo Servin
Cc: Nick Hilliard; [email-masked]; Scott Mansfield
Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

> http://tools.ietf.org/html/draft-ietf-opsec-v6-02

There are *many* in opsec -- all of which the ITU document apparently ignored.

Cheers,

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 13 Jun 2013 11:57:35 +0100

On 10/06/2013 12:03, Scott Mansfield wrote:
> During Additional Review, only comments on the modified sections of the
> document are allowed.

Scott,

This document is of sufficiently poor quality that in order to make it
useful, it would need to be substantially rewritten by someone with a
significantly better understanding of both ipv6 and security.  I don't
think that its problems can be rectified by submitting limited comments on
prespecified sections, and if the IETF does this, it could be construed as
giving its imprimatur to the document.  I believe that this could reflect
badly on the IETF and on that basis I think it would be a bad idea for the
IETF to submit comments.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 13:57:35 +0200

> badly on the IETF and on that basis I think it would be a bad idea for the

+1

(although I have no idea if the problem is who the document was written
by, whether they didn't do the homework to see what e.g. the IETF has
been doing in this area, both, or what).

Cheers,

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 13 Jun 2013 13:03:43 +0000

I think a nice liaison to the next SG17 meeting is in order that lists the work that Sec Area is doing.  Something that would provide an FYI for future work.  That is exactly what an informational liaison is for.  Anyone up for helping craft such an overview?  

Regards,
-scott.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, June 13, 2013 7:58 AM
To: Nick Hilliard
Cc: Scott Mansfield; [email-masked]
Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

On 06/13/2013 12:57 PM, Nick Hilliard wrote:
>> During Additional Review, only comments on the modified sections of 
>> the document are allowed.
> 
> Scott,
> 
> think that its problems can be rectified by submitting limited 
> comments on prespecified sections, and if the IETF does this, it could 
> be construed as giving its imprimatur to the document.  I believe that 
> this could reflect badly on the IETF and on that basis I think it 
> would be a bad idea for the IETF to submit comments.

+1

(although I have no idea if the problem is who the document was written by, whether they didn't do the homework to see what e.g. the IETF has been doing in this area, both, or what).

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 18:59:16 +0200

On 06/13/2013 03:03 PM, Scott Mansfield wrote:
> I think a nice liaison to the next SG17 meeting is in order that
> lists the work that Sec Area is doing.  Something that would provide
> an FYI for future work.  That is exactly what an informational
> liaison is for.  Anyone up for helping craft such an overview?

FWIW, most of the IPv6 security work is done in the Internet Area and
the Operations area.

That aside, I'm curious about the objetive of a liason such as the
current one -- I hope nobody reads it as the IETF having somehow
rubber-stamped the document that ITU-T will eventually publish.

Thanks,

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 13 Jun 2013 17:12:31 +0000

The objective of the liaison in question was to inform the IETF community what is going on in SG17.  Since the working documents are not open to the public, non ITU members have to rely on this type of liaison from the ITU in order to see the documents as they are progressing through the process.   It is important to be aware of how various individuals/institutions/governments interpret the liaisons that fly back and forth, however, controlling that interpretation is difficult.  So, (in my opinion), the best way to handle situations like this is evaluate if it is worth assisting to make the liaised document better, or if the situation warrants simply providing pointers to related work that will help raise awareness of existing work to help their work moving forward.  This situation seems to fall into the latter case.  If there is interest in creating material that individuals think would be of use to SG17, I can help formulate that material into an informational liaison.

Regards,
-scott.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, June 13, 2013 12:59 PM
To: Scott Mansfield
Cc: Nick Hilliard; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6

On 06/13/2013 03:03 PM, Scott Mansfield wrote:
> I think a nice liaison to the next SG17 meeting is in order that lists 
> the work that Sec Area is doing.  Something that would provide an FYI 
> for future work.  That is exactly what an informational liaison is 
> for.  Anyone up for helping craft such an overview?

FWIW, most of the IPv6 security work is done in the Internet Area and the Operations area.

That aside, I'm curious about the objetive of a liason such as the current one -- I hope nobody reads it as the IETF having somehow rubber-stamped the document that ITU-T will eventually publish.

Thanks,

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 13 Jun 2013 18:19:19 +0100

On 13/06/2013 15:56, SM wrote:
> The IETF cannot say that the document is of poor quality.

Indeed not: for the record, my comments were solely a reflection of my
personal opinion on the contents of the document.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jun 2013 08:19:39 +1200

> been doing in this area, both, or what).

That's why Scott's *positive* suggestion is a good one - generate a new
liaison document describing current IETF work (not a reply to the liaison
document from them). And Fernando... you are better placed than most
people to provide the technical content of that liaison.

As far as X.1037 itself is concerned, it really should not proceed in its
current state, but I don't know whether a liaison reply is allowed to say
that. Perhaps our liaison document should be entitled "Alternative formulation
of technical security guidelines on deploying IPv6", which would make
our opinion pretty clear.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Jun 2013 00:16:23 +0200

Hi, Brian,

> people to provide the technical content of that liaison.

I volunteer to help in that area.

What I'm wondering (since I don't know much about "liasons" in general)
is what the "administrative" content should be.

For example, the current liason talks about "continue cooperation with
the IETF Sec Area". This makes me wonder about (among others), these things:

* It looks like this kind fo liason should be with the IETF as a whole
-- because some topics can fall in many different areas. For example,
I've done IPv6 security stuff on v6ops & opsec (OPS area) and 6man (INT
area). I'd bet there's more IPv6 security stuff in INT are or OPS area
than in SEC area, for instance. So I guess the IETF as a whole (or at
least INT area, OPS area, and SEC area) should be involved.

* There should be clear procedures regarding how cooperation would work.
When I asked how one was supposed to help in this effort the mechanism
was unclear.

As a result of the above, I guess ITU-T can claim that their document is
a product of their cooperation with the IETF, where most IETFers seem to
think the document is far from good.

I don't care about this particular document. But I think these aspects
should be improved for any future liasons of this sort.

> our opinion pretty clear.

At which point, one would ask "why have the liason, anyway?".

P.S.: FWIW, I'm always keen to cooperate with anyone/any organization.
Discussion an cooperation can always help all parties improve their
understanding of a topic. The problem here is that it is not clear
whether real cooperation was intended on teh part of ITU, and, in such
case, how it was supposed to happen.

Cheers,

---

From: SM <[email-masked]>
Date: Thu, 13 Jun 2013 16:03:28 -0700

Hi Fernando,
>the IETF Sec Area". This makes me wonder about (among others), these things:

If a person is not familiar with the IETF and the person is working 
on security he or she would pick the Security Area.

>least INT area, OPS area, and SEC area) should be involved.

The liaison might point out the appropriate area (see comment 
above).  This topic has been raised on three IETF mailing 
lists.  Most people in INT or OPS have likely seen some parts of the 
discussion.

>When I asked how one was supposed to help in this effort the mechanism

A Security Area Director, in an individual capacity, commented about 
this.  I thought that you saw that message.  Scott Mansfield 
explained the procedures too.  There was a call for comments last 
year about the cooperation.  People might not have paid attention to 
it as it is process stuff.  It's too late to do much on this one.

>think the document is far from good.

Yes.

>At which point, one would ask "why have the liason, anyway?".

It's to help the two organizations interact with each other.

>case, how it was supposed to happen.

There is some politics.

Regards,
-sm

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Jun 2013 23:46:16 +0000

As someone who's been tasked in the past to write numerous liaison statements to IETF and to ITU-T, and who has some experience with IETF and read through the IETF liaison process doc (RFC 4052), but who has little understanding of IPv6 security issues and isn't subscribed to any of the other lists where this is being discussed, I would like to offer some friendly advice on what I would probably do to create a positive outcome in this case.

1. Do not assume that they have bad intentions or are trying to work in a closed manner or be disrespectful towards IETF. Assume rather that they really would appreciate comments from IETF. 
2. Do not assume they have an in depth understanding of how IETF works.
3. Note that the 3 contacts are from Japan and Uganda and recognize that you may be dealing with both language barriers and cultural differences. It's also useful to understand that the Japanese have found ITU-T to be a good place for them to do standards work.
4. Have someone with knowledge of the IETF concerns reach out to the listed co-editor (cc to rapporteur and chair) and say that many individuals in IETF have concerns, and that it might be good to have a one-on-one conversation between the IETF someone and the co-editor. As individuals. During the conversation, step through the document and discuss concerns. Then discuss what sort of liaison response would be helpful for the co-editor to achieve the desired outcome for influencing the document.
5. The IETF someone then crafts the response based on what was agreed during that discussion. Further IETF processes as described in RFC 4052 ensue. Which also means the IETF someone should probably be selected by a WG chair, AD or other IETF leadership person, as per RFC 4052.

I've done liaisons in the past from BBF to ITU-T SGs where the ITU-T document editors were Japanese and they were wanting comments from BBF. When I first saw the document they were writing, I had this same sort of "OMG what the heck is this?" response that I'm seeing here. What I describe above is what I did (substitute IETF with BBF). It worked. Yes, there are formalities that need to get followed. But the best results were achieved by agreeing on the formal response as a result of informal one-on-one discussion. And it was worth the effort.
Barbara

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Jun 2013 02:38:55 +0200

On 06/14/2013 01:03 AM, SM wrote:
> If a person is not familiar with the IETF and the person is working on
> security he or she would pick the Security Area.

But I bet the IETF has a say there, right?

> this.  I thought that you saw that message.

IMO, the process wasn't straightforward.

Besides, reading Barbara's recent post, it looks like we need to get
consensus on the actual response (or something similar to that).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Jun 2013 02:34:16 +0200

On 06/14/2013 01:46 AM, STARK, BARBARA H wrote:
> As someone who's been tasked in the past to write numerous liaison
> statements to IETF and to ITU-T, and who has some experience with
> IETF and read through the IETF liaison process doc (RFC 4052), but
> who has little understanding of IPv6 security issues and isn't
> subscribed to any of the other lists where this is being discussed, I
> would like to offer some friendly advice on what I would probably do
> to create a positive outcome in this case.
[...]

FWIW, I haven't assumed anything (nor do I have any reasons to do so).

However, I do believe that these issues should be clearer to us (how to
contribute, etc., etc.), and if cooperation is expected, we shouldn't
need to find an ITU-T member that relays our comments... because that
rather discourages reviews and cooperation.

P.S.: As noted before, I don't know much about the liason process -- so
my opinions might reflect that.

Thanks!

Best regards,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2013 01:25:26 +0000

> rather discourages reviews and cooperation.

The way issues get clearer is by doing what Barbara did, or by listening to Barbara tell you what she did.   There isn't somebody whose job it is to make this work.   ITU people have no obligation to cooperate with us.   We have no obligation to cooperate with them.   We do it because we think it's worthwhile.

As a general principle, IMHO, Barbara's attitude here is the right one.   It does matter whether the ITU-T publishes bogus documents, because people will write laws referencing those documents, and in many cases they _can't_ write laws referencing our documents—in many countries around the world, what SDO's documents can be referenced in law is codified, and typically the IETF isn't an organization that's codified.   So when the ITU-T makes a standard that says the wrong stuff, it can have a really significant impact.

This is not to say that it's your problem to fix this, but what Barbara is proposing here is very good advice, and it would be good if _someone_ here followed it.   I can't, for lack of time, but maybe someone can.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Jun 2013 04:38:05 +0200

> liaison is for.  Anyone up for helping craft such an overview?

If the liason is about v6 security, you should really consider what
we're ding in OPS and INT, too. I can help, if needed.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jun 2013 16:52:00 +1200

> rather discourages reviews and cooperation.

Nevertheless, there is no choice: only an ITU-T member, such as a
sector member (an institution, not a person) can contribute.
Barbara is 100% correct, and Scott is our channel.

But don't expect dialogue.

Don't worry about the admin part, that is cut-and-paste at the end.
If you provide technical text and precise references, that is
the hard work done.

    Brian

---

From: t.petch <[email-masked]>
Date: Fri, 14 Jun 2013 10:09:56 +0100

----- Original Message -----
From: "Fernando Gont" <[email-masked]>
To: "STARK, BARBARA H" <[email-masked]>
Cc: <[email-masked]>; "Scott Mansfield" <[email-masked]>
Sent: Friday, June 14, 2013 1:34 AM

Fernando

Think of the ITU-T as the political wing of standards making.  Just as
you cannot walk into the United Nations and address the Security
Council, so you have to go through the approved paths in order to get
material before the ITU-T.  Just as they think that the Security Area is
the right contact, so we might think that a particular Question of a
particular Study Group is the right forum for our ideas, but what do we
know?  Hence the existence of a nominated Liaison within the IETF whom
we have to use.

Liaisons are listed at
http://datatracker.ietf.org/liaison/
and it is no coincidence how many of them involve MPLS and SG15 (which
work I tracked).

Current liaisons are at
http://www.ietf.org/liaison/managers.html
Think of them as an application gateway, but like anyone in the IETF, a
volunteer with a limit on the time available to perform this valuable
function.  We produce something that fulfils our processes, such as an
I-D with consensus, and the gateway turns that into the ITU-T
equivalent.  The ITU-T make heavy use of Word, PDF and such like,
sometimes with more advanced versions thereof than I can decipher (just
as the IETF web site defeats me with its use of TLS), but that usually
gets taken care of.

If you can lead the production of the technical content, showing the
breadth of work on IPv6 security within the IETF, then I am confident
that the rest will get taken care of.

Tom Petch

---

From: SM <[email-masked]>
Date: Fri, 14 Jun 2013 02:42:05 -0700

Hi Fernando,
>But I bet the IETF has a say there, right?

If it is done informally, yes.

>IMO, the process wasn't straightforward.

Agreed.

>consensus on the actual response (or something similar to that).

Yes.  Someone will have to put in the effort to build agreement.

I don't know the impact of ITU-T X.1037.  As Ted Lemon mentioned it 
might be codified in national regulations.

Regards,
-sm

---

From: Arturo Servin <[email-masked]>
Date: Sat, 15 Jun 2013 11:58:53 -0400

Scott,

    I think Fernando volunteered (haven't finished the whole thread if
somebody else has volunteered too) . I could add some help as well if
needed.

Regards,
as