Subject: [v6ops] ITU-T SG17 IPv6 security work items liaison

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Jun 2011 17:53:55 +0100

Hi all,

We received a liaison [1] from ITU-T saying they're
planning to start a couple of work items on the
security of IPv6. As far as we know, they envisage
developing a "technical guideline on deploying IPv6"
and "Security Management Guideline for implementation
of IPv6 environment in telecommunications
organizations." Bear in mind that they're just starting
so they know about as much as we would just before a
BoF or something like that.

I think we'd like to respond to them that that's great,
and we'll be interested in their results, but can they
*please* come back to us before saying something should
be changed so's we can talk about it.

If you've comments or ideas on that, please respond
to this in the next week. At that point, we'll
get some help translating this into liaison-speak
(thanks Eliot:-) and send the result to these lists for
a quick check before shipping it off to the ITU-T
folks.

Cheers,
S.

[1] https://datatracker.ietf.org/liaison/1047/

---

From: John Leslie <[email-masked]>
Date: Sat, 4 Jun 2011 23:10:45 -0400

> be changed so's we can talk about it.

   I don't think that's quite right. We should welcome their studying
security issues; but I think we need to _strongly_ encourage them to
start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since
it has _significant_ changes from RFC 4294 (and an ITU-T study based
on RFC4294 will be of rather limited value).

   Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol
or the Node Requirements. The language there should talk of documenting
security "concerns" or "issues" or whatever term seems neutral enough;
and list as the next step exchanging ideas of what "changes" might help.

   Clearly, ITU-T is entirely justified in publishing recommendations
of what level of security-related-trust to place in IPv6 packet
forwarding: but any protocol _changes_ are outside their bailiwick.

   (As an aside, IETF should resist most proposals for change until
IPv6 sees widespread deployment -- deploying to a moving target is
just TOO risky.)

--
John Leslie <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Jun 2011 23:10:11 -0700

> be changed so's we can talk about it.

That seems like a reasonable proposal. 

There a, of course, several proposed sets of security guidelines for IPv6 floating in the breeze. If you want my druthers, I would like to see a comprehensive security *architecture*. Steve Kent wrote to me last month, on another topic, saying

> I do have a few comments about the discuss of secruity, in general. I see that you used the CIA model for describing security requirements/services. Although this is a commonly used model, I find it inferior to the model that was developed by ISO in the mid 80's (ISO 7498-2).

It might be worthwhile to look at the ISO model he suggests as a possible starting point. 

To my mind, anything resembling a security architecture will identify threats at the physical, link, network (LAN and IP), transport, and applications layers, and make recommendations for addressing them - and not start from the premise of a global federated identity, which doesn't exist.

---

From: Tina Tsou <[email-masked]>
Date: Sat, 04 Jun 2011 23:25:03 -0700

Hi,
RFC 4775 is the process to follow.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred
Baker
Sent: Saturday, June 04, 2011 11:10 PM
To: Stephen Farrell
Cc: Turner, Sean P.; [email-masked]; [email-masked]; [email-masked]; Eliot
Lear
Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison

There a, of course, several proposed sets of security guidelines for IPv6
floating in the breeze. If you want my druthers, I would like to see a
comprehensive security *architecture*. Steve Kent wrote to me last month, on
another topic, saying

> I do have a few comments about the discuss of secruity, in general. I see
that you used the CIA model for describing security requirements/services.
Although this is a commonly used model, I find it inferior to the model that
was developed by ISO in the mid 80's (ISO 7498-2).

It might be worthwhile to look at the ISO model he suggests as a possible
starting point. 

To my mind, anything resembling a security architecture will identify
threats at the physical, link, network (LAN and IP), transport, and
applications layers, and make recommendations for addressing them - and not
start from the premise of a global federated identity, which doesn't exist.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Jun 2011 23:33:24 -0700

BTW, in case it wasn't clear, I think the IETF should do that architecture.

On Jun 4, 2011, at 11:10 PM, Fred Baker wrote:

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

---

From: Arturo Servin <[email-masked]>
Date: Sun, 5 Jun 2011 17:30:54 -0300

I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if  they use our work as a foundation.

just my 20 cents
-as

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Jun 2011 12:06:02 +0200

Arturo,

> 	I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good…

There are several specific areas of interest that you can view at
https://datatracker.ietf.org/documents/LIAISON/file1228.pdf.  The
chairman and vice-chairman of the ITU's security area, SG17, are
informing us that two of their working groups which the ITU-T calls
Questions will be taking on new work relating to IPv6.

Let's review the two work items:

The first thing to note is that X.ipv6-secguide is targeted to be a
deployment guide.  We need more of these for IPv6 and we should welcome
the ITU-T's involvement.

The second document, X.mgv6 is meant to be "management guidelines for
implementation of IPv6".   We provide a fair amount of this sort of
guidance in our collective works.  Also, the difference between
implementation guidance and normative statements can be very narrow. 
Therefore, this is the area most likely to have overlap.  The best way
to address that overlap is to communicate effectively through the
liaison process, and perhaps to also participate directly in the
meetings, when possible.

Here the chairman and vice-chairman of SG17 have recognized that the
IETF is an important player in the work to be done.  While no response
has been requested, it would be wise for us to provide the relevant
related work so, as you say, the ITU-T doesn't attempt to start from
scratch.  I hasten to point out that they are by no means starting from
scratch, but we should still provide them relevant guidance.  So what is
relevant guidance?  That can take several different forms:

   1. Direct participation in the Study Group meetings.  Study Group
      meetings are open to Member States and Sector Members.  ISOC is a
      Sector Member.  The IETF on its own is not.
   2. Concise and relevant liaison statements.  As this work is just
      beginning, we can point to not only the published RFCs that are
      relevant, and they include not only RFC 4294 and
      draft-ietf-6man-node-req-bis (and we can reference this as a work
      in progress, and in fact invite comment), but also relevant
      portions of other RFCs, particular their relevant Security
      Considerations sections.
   3. Informal consultations with ITU-T participants.  Believe it or
      not, this is often the most effective way to contribute.

At the same time we should invite SG17 to provide us any feedback on our
works, especially when they discover any of the following:

    * A security problem;
    * An obstacle to deployment; or
    * An interoperability problem.

While this solicitation should not be limited to the ITU-T, that
organization has a reach into the developing world that quite frankly we
do not, and they may spot issues that relate to certain environments.

Hope this helps,

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jun 2011 12:41:34 +0100

On 05/06/11 21:30, Arturo Servin wrote:
> 
> 	I do not see why the ITU has to start from zero. 

What Eliot said.

> There are several (or some at least) very good RFC and I+D documents related to IPv6 security. 

Sure. Feel free to send RFC numbers and we'll include
some in the draft response that we'll circulate in a
while. (So no need to spam everyone with those, just
sending your suggestions to Eliot, Sean and I will be
enough.)

Thanks,
S.

> I think we should recommend them to ITU, it is good that they let us
know, it would be better if  they use our work as a foundation.

---

From: "Williams, Marcus (Contractor)" <[email-masked]>
Date: Mon, 6 Jun 2011 07:58:43 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stephen Farrell
> Sent: Monday, June 06, 2011 7:42 AM

> sending your suggestions to Eliot, Sean and I will be

There are a number of RFCs including 4291 already referenced in this NIST Special Publication 800-119, Guidelines for the Secure Deployment of IPv6:

http://csrc.nist.gov/publications/PubsDrafts.html#800-119

Marcus Williams, CISSP

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jun 2011 22:24:02 -0300

> on RFC4294 will be of rather limited value).

While I have not read the latest version of the aforementioned I-D, I
don't think it address (nor should it) the security implications of
IPv6. As a simply example, while there has been some work on the
security implications of transition/co-existence technologies, I don't
think there have been e.g. best practices published on e.g. how to
filter them (in those environments in which the use of technologies such
as Teredo is undesirable). Additionally, I don't think there has been
much work on which tools could be used (and how) to perform network
monitoring (e.g., use NDPMon to monitor ND-based attacks).

> forwarding: but any protocol _changes_ are outside their bailiwick.

Agreed. However (and with no clue about what ITU-T is planning to work
on) I guess there's room for recommendations on  what stuff to filter,
specific features that should be enabled/disabled, etc.

> IPv6 sees widespread deployment -- deploying to a moving target is

While I do see some value in this point (and I'm aware there are many
that share this point of view), I think this argument does not
necessarily apply to security. If a flaw is identified, and there's a
concrete proposal to mitigate it, I don't think it would be a good idea
to resist to *this* type of change/update.

Thanks!

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 00:09:13 +0100

All,

Thanks for the feedback on this liaison. Eliot (mostly)
and I (a bit) have tried to capture all that in the
text below. Please send any comments on that (with
specific alternative text) in the next week and then
we'll shoot it on to them.

RFC 3514 does have some words about IPv6 - should I
add that as a reference? :-)

Thanks,
Stephen.

From:  IETF Security Area
To: Study Group 17, Questions 2 and 3
Title: Work on Security of IPv6

FOR ACTION

The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6
security issues".  As the world transitions to IPv6, new opportunities
and challenges and challenges arise.  SG17's new focus on deployment and
implementation considerations reflects this reality.   We would like to
bring to your attention the following work which we believe may prove a
useful basis for both X.ipv6-secguide and X.mgv6:

    * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently
      under revision)
    * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node
      Requirements RFC 4294-bis"
    * RFC 4864 – "Local Network Protection for IPv6"
    * RFC 6092 – "Recommended Simple Security Capabilities in Customer
      Premise Equipment (CPE) for Providing Residential IPv6 Internet
      Service"
    * RFC 6105 – "IPv6 Router Advertisement Guard"
    * RFC 6106 – "IPv6 Router Advertisement Options for DNS
      Configuration", §7 in particular.

As you are aware, every RFC contains a Security Considerations section.
In developing either a implementation or deployment guide, contributors
are strongly encouraged to review the RFCs and Internet-Drafts that
support any underlying function.

In addition, we bring to your attention the following IETF Working
Groups that are working on security-related work of IPv6:

Working Group  Purpose                     Mailing list address
Name

6man           IPv6 Maintenance            [email-masked]
savi           Source Address Validation   [email-masked]
               Improvements
dhc            Dynamic Host Configuration  [email-masked]
v6ops          IPv6 Operations             [email-masked]
opsec          Operational Security        [email-masked]
               Capabilities for an IP
               Network

In addition to the above working groups, the Security Area of the IETF
maintains a mailing list for general discussion, [email-masked].  We
encourage and invite open and informal discussion in these or other
relevant IETF fora on this very important topic. As with all IETF
working groups, any and all interested parties can choose to directly
contribute via the mailing lists above.

As in other areas, the Security Area of the IETF invites SG17 to bring
any new-found concerns about IETF protocols to our attention so that as
and when we revise our documents we can make appropriate amendments to
IETF protocols. In particular, as this planned work matures, we would
welcome hearing about it in more detail, perhaps via an invited
presentation at a saag meeting or via review of draft documents as may
be appropriate.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 01:01:22 +0100

Thanks Russ, will make those changes.
S.

On 14/06/11 00:57, Russ Housley wrote:
> Stephen:
> Comments below.
> Russ
> s/and challenges and challenges/and challenges/
> s/new//
> 
> Why not just reference the bis document?
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Jun 2011 19:57:49 -0400

Stephen:

Comments below.

Russ

---

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Jun 2011 07:51:35 +0300

Russ,

>>     Requirements RFC 4294-bis"

The draft could also say that the working group has reached consensus and has submitted it to the IESG for publication on 25 May 2011.

Bob

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 08:19:52 +0100

> The draft could also say that the working group has reached consensus and has submitted it to the IESG for publication on 25 May 2011.

Will do,
S

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jun 2011 11:00:24 +0100

>        Configuration", §7 in particular.

maybe mention draft-gont-v6ops-ra-guard-evasion?  It's not a strategic 
focused document, but gives specific advice on a specific issue which is 
relevant to ipv6 lan deployments.

Nick

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 12:07:17 +0100

Thanks Nick,

I'll add that unless someone tells me its a bad plan.
Its a fairly fresh I-D, but I guess it looks pretty
relevant all right.

S.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Jun 2011 11:30:32 -0400

Hi Stephen,
   Please consider adding the following RFCs to the list.

RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats
RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
RFC4942 IPv6 Transition/Co-existence Security Considerations
RFC5157 IPv6 Implications for Network Scanning

Thanks
Suresh

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Jun 2011 17:17:17 -0700

Hi, all,

It'd be useful to wait until these docs (this v6ops one and the 6man one 
it refers) are adopted by the relevant WGs before noting them in 
recommendations to external parties, IMO.

Some of the recommendations in these documents are akin to "if I didn't 
expect it, it's an attack", which I feel makes our protocols too brittle 
unless we are in a situation of known security compromise via other 
indicators. The latter doc (6man) also silently discards legitimate 
packets (complicating debugging), and ends up deprecating the entire 
extension header feature of IPv6 for all IPv6 signaling protocols - 
which seems like a bad idea overall.

I'd prefer to see the relevant WGs endorse these as useful ways forward 
before adding them to this list.

Joe

On 6/14/2011 4:07 AM, Stephen Farrell wrote:
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jun 2011 01:32:22 +0100

Hi Joe,

Fair point about the draft-gont document. I've taken it out
for now.

Which was the 6man I-D you meant? There are now two referenced
thanks to recent comments and both are draft-ietf-6man so have
presumably been adopted by the WG.

My current version is attached following today's edits in case
that helps.

I've still not included rfc 3514 but the more iterations this
takes, the more I'm getting more tempted:-)

Thanks,
S.

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Jun 2011 17:35:49 -0700

On 6/14/2011 5:32 PM, Stephen Farrell wrote:
> Which was the 6man I-D you meant?

The one ref'd inside the draft-gont-v6ops doc - it's draft-gont-6man...

There aren't issues with the draft-ietf-6man docs.

Joe

> There are now two referenced

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Jun 2011 17:42:18 -0700

> RFC5157 IPv6 Implications for Network Scanning

Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jun 2011 02:01:49 +0100

All,

> Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild.

Ok, that's not currently included and given its not
clear (to me at least) I'm gonna leave it out.

I think we've accumulated enough references at this
point - its never going to be a complete list and
even if it attempted to be such, it'd probably be
so long as to be useless.

So I'm no longer taking additional reference
recommendations unless a whole bunch of people
say the same thing and otherwise I'm gonna stick
with the current list as sent in a reply to Joe
Touch a few minutes ago.

If there're text edits that are *needed* then I'll
take those for a couple of days more but I reckon
we've iterated enough here.

Thanks for all the help with this, I think we're
done now basically.

Cheers,
S.

---

From: Tim Chown <[email-masked]>
Date: Wed, 15 Jun 2011 10:44:14 +0100

> Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild.

I just re-read the abstract and conclusion to 5157, and I think everything stated there still applies.

The bit where we stated that we'd not seen traditional network scanning at our own site (to <prefix>::1, <prefix>::2, etc) is the part that has changed - we could now say there is some evidence of such activity.  But that doesn't invalidate the advice to - for example - not have your DHCPv6 pools start with <prefix>::1, or the observation that attackers will look at other ways to glean addresses, with some discussion of those.

The interesting newly discussed issue since 5157 was published is the possible impact on ND caches of scanning dark space, should such sweeps reach the target subnet/link.

WRT the ITU-T doc, I agree it's probably not needed.

Tim

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Jun 2011 17:10:41 +0200

Joe,

<Liaison>

A suggestion just on this one point:
> I'd prefer to see the relevant WGs endorse these as useful ways
> forward before adding them to this list.
>

It is good for the IETF to provide the ITU's membership an opportunity
to comment either formally via the liaison process or informally as
individuals before work is finalized, just as we would like that
opportunity.  So long as we are clear on the status of the work, and the
work can reasonably be construed as relevant, it's okay to mention it. 
Now, how should one apply my advice (which is what this is) to your
suggestion?

</Liaison>

Regards,

Eliot

---

From: "t.petch" <[email-masked]>
Date: Wed, 15 Jun 2011 17:22:24 +0200

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: <[email-masked]>; "Nick Hilliard" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Stephen Farrell" <[email-masked]>
Sent: Wednesday, June 15, 2011 5:10 PM

Eliot

I do not think that it is enough for us to be clear on the status of the work;
it is the other SDO that needs to be clear.

We know how to interpret a 9 month old I-D without the word 'ietf' in
its name and with an intended status of Experimental.  The ITU-T do not.

So Joe's comment that the WG should endorse the work before we
liaise it I think spot on (and I think that Stephen has taken this on
board).  We have arcane practices and terminology that are
incomprehensible to other SDO so we have a responsibility to
make things - such as status - clear, in language that will not be
misunderstood.  Thus we know that the first draft adopted by a WG
is almost always wrong, simply because the adoption process
forbids changes; you must wait for -01 or -02 before you have
something that starts to resemble the views of the WG.  Obvious,
but not to another SDO.  We need to spell such matters out.

Tom Petch

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Jun 2011 19:07:27 +0200

Tom,

> its name and with an intended status of Experimental.  The ITU-T do not.

You're absolutely right.  We have to set the context for the ITU on the
work we are mentioning, whatever that work may be.  Otherwise, why
mention it?

> board).

The key is that there be general agreement about what information is to
be shared, whether it is a working group document or not.  That said,
one tends to be more competent when we speak of our own work.  Even is
work is being considered for adoption by a working group, that is also
information that can be shared.

>   We have arcane practices and terminology that are
> misunderstood.  

100% agree!

Eliot

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Jun 2011 14:00:55 -0700

Hi, all,

> information that can be shared.

We don't dump our email discussions on the ITU , nor do we discuss with 
them all of the potential WG docs that are suggested during discussions 
(based on this thread at least).

While I wouldn't hide any major surprises in the works, we should 
forward work that represents the IETF. WG adoption is the clear 
indicator of that.

AFAICT, the goal is to let them know where we're going. I think the list 
of WG docs does that.

Joe