Subject: Agenda issue

From: Fred Baker <[email-masked]>
Date: Wed, 4 Mar 2009 18:16:16 -0800

I have gotten a number of folks asking for time on the agenda, but I  
have a problem:

-rw-rw-r--  1 fred  fred   19268 Sep 10 05:33 draft-ietf-v6ops-ra- 
guard-01.txt
-rw-rw-r--  1 fred  fred   61870 Sep 29 08:52 draft-miyata-v6ops- 
snatpt-02.txt
-rw-rw-r--  1 fred  fred   48468 Oct  1 10:58 draft-endo-v6ops- 
dnsproxy-01.txt
-rw-rw-r--  1 fred  fred   43841 Oct 15 10:48 draft-ietf-v6ops-tunnel- 
security-concerns-
01.txt
-rw-rw-r--  1 fred  fred   18562 Oct 15 10:48 draft-krishnan-v6ops- 
teredo-update-04.txt
-rw-rw-r--  1 fred  fred   53090 Oct 30 10:22 draft-wbeebee-ipv6-cpe- 
router-03.txt
-rw-rw-r--  1 fred  fred   36662 Nov  3 10:15 draft-bajko-v6ops-port- 
restricted-ipaddr-a
ssign-02.txt
-rw-rw-r--  1 fred  fred   48973 Nov  3 11:06 draft-luo-v6ops-6man- 
shim6-lbam-00.txt
-rw-rw-r--  1 fred  fred   30429 Nov  3 14:26 draft-chown-v6ops-rogue- 
ra-02.txt
-rw-rw-r--  1 fred  fred  134587 Nov  3 16:14 draft-thaler-v6ops- 
teredo-extensions-02.tx
t
-rw-rw-r--  1 fred  fred   16462 Feb 17 14:52 draft-rgaglian-v6ops- 
v6inixp-01.txt
-rw-rw-r--  1 fred  fred    9716 Feb 18 08:01 draft-denis-v6ops-nat- 
addrsel-00.txt
-rw-rw-r--  1 fred  fred   41369 Feb 23 22:05 draft-bnss-v6ops- 
upnp-00.txt
-rw-rw-r--  1 fred  fred   19211 Mar  4 14:11 draft-vyncke-vdv-v6ops- 
conf-stats-00.txt

I see four new drafts post-Minneapolis. The Rogue RA and Teredo  
drafts, whose last call completed several months ago and the write-up  
is awaiting new drafts, don't have new drafts.

Hello? Anyone out there? I need new drafts (cut-off date is Friday)  
for anything folks expect to discuss in the WG meeting...

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Mar 2009 22:24:20 +0000

> -rw-rw-r--  1 fred  fred   30429 Nov  3 14:26 draft-chown-v6ops-rogue- 

Stig and I have released a new version, in which we attempt to answer the
list comments:

* Switched focus to accidental RAs - Jinmei
* Clarified valid lifetime
* Reworded DHCP gateway text, noted new draft by Thomas
* Added isolation text - Bob H
* SeND deployment issues expanded - Thomas
* DHCPv6 gateway reworded - emphasised shifting problem

Plus other minor edits and reoriganising.

Tim

-- snip

A New Internet-Draft is available from the on-line Internet-Drafts directories. 

        Title           : Rogue IPv6 Router Advertisement Problem Statement
        Author(s)       : T. Chown, S. Venaas
        Filename        : draft-chown-v6ops-rogue-ra-03.txt
        Pages           : 16
        Date            : 2009-03-09

When deploying IPv6, whether IPv6-only or dual-stack, routers are
configured to send IPv6 Router Advertisements to convey information
to nodes that enable them to autoconfigure on the network.  This
information includes the implied default router address taken from
the observed source address of the Router Advertisement (RA) message,
as well as on-link prefix information.  However, unintended
misconfigurations by users or administrators, or possibly malicious
attacks on the network, may lead to bogus RAs being present, which in
turn can cause operational problems for hosts on the network.  In
this draft we summarise the scenarios in which rogue RAs may be
observed and present a list of possible solutions to the problem.  We
focus on the unintended causes of rogue RAs in the text.  The goal of
this text is to be Informational, and as such to present a framework
around which solutions can be proposed and discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chown-v6ops-rogue-ra-03.txt

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 13 Mar 2009 20:21:00 -0700

At Mon, 9 Mar 2009 22:24:20 +0000,

> Plus other minor edits and reoriganising.

I've read the 03 version, and confirmed that my concern on the
previous version was clearly addressed (thanks!).  I don't know the
intended next step of this document, whether to adopt it as a wg item
or to submit it to the IESG, but I support it in either case.

I have some minor (mostly) editorial comments on 03 as follows:

p.8 Section 3.8: I guess the following paragraph were intended to be
out of scope (simply removed?) according to the revised focus of this
document:

   In contrast though, an attacker might use such a tool to learn about
   prefixes being advertised on a link and to deprecate the 'good' RA(s)
   in favour of their bogus RA(s).

p.11 Section 4: I failed to parse the following part.  There is
perhaps missing text between "configuration" and "However"?

   [...]  On that basis the RA snooping proposal, e.g.  RA
   Guard, has merit, while approaches like manual configuration However
   RA Guard is not yet fully defined or available, while only certain
   managed switch equipment may support the required ACLs.

p.12 Section 5.1: I was not sure if the following part is intended to
be out of scope or is just mentioned to compare with the accidental
rogue RA case:

   It is
   thus possible for an attacker to target one or more hosts on a shared
   medium without (potentially) a rogue multicast RA being observed
   elsewhere on the network (e.g. by a monitoring daemon).

If it's the latter, it would be better to clarify the intent.

p.13 Section 5.5: I understand the following text is a revision to
address my previous comment, but technically it's still 100% clear:

   e.g. considering the '2
   hour rule' of Section 5.5.3 of RFC4862 (though this applies to the
   valid lifetime not the router lifetime).  We should ensure that

the 2 hour rule only applies to valid "address" lifetime.  Although
the prefix lifetime doesn't officially use this qualifier (since
a prefix only has "the lifetime"), it could be confusing as it's
normally configured from the valid lifetime field of an RA prefix
information option.  So, I'd clearly say "valid address lifetime".

p.14 Section 6: based on the intent of the revise, I'd rephrase
"security risk" with "robustness issue" or something:

   Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6
   host configuration by DHCP only, and be a method that IPv4
   administrators are comfortable with (for better or worse), but this
   simply shifts the security risk elsewhere.

And very minor nits follow:

p.4 Section 1: there are duplicate "also"s. I'd remove one of them:

   appears more common in shared wireless environments, it is also seen
   on wired enterprise networks also.

p.4 Section 1: I don't like undefined acronyms:-)

   the RA message.  In addition, rogue RAs can cause hosts to assume
   wrong prefixes for their SLAAC addresses.  In a case where there may

Since this is the only occurrence, I'd simply say "wrong prefixes to
be used for stateless address autoconfiguration".

p.5 Section 2.2: s/an problem/a problem/

   bridging two subnets together, causing an problem similar to VLAN

p.7 Section 3.5: s/send/sends/

   accidentally send out a rogue RA on the network has configured their

p.8 Section 3.7: s/no thus/thus/

   in the filter may become incorrect and no thus no method would be

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Mar 2009 11:14:31 -0700

You said that you don't know the plan for this draft. Let me tell you  
*my* plan, and what I thought the WG told was its plan. If I have it  
wrong, I would rather know now.

We have two drafts before the house:
http://tools.ietf.org/html/draft-chown-v6ops-rogue-ra
   "Rogue IPv6 Router Advertisement Problem Statement", Tim Chown,  
Stig Venaas,
   9-Mar-09, <draft-chown-v6ops-rogue-ra-03.txt>

http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard
   "IPv6 RA-Guard", Eric Levy-Abegnoli, Gunter Van de Velde, Chip  
Popoviciu,
   Janos Mohacsi, 5-Mar-09, <draft-ietf-v6ops-ra-guard-02.txt>

Tim's is essentially a problem statement, and the other is a proposed  
operational solution. Note that it is not a protocol, although it has  
a state machine; it is a behavior of a system within a context. We  
have been through last call on both drafts, and I have been planning  
to send both to Ron to publish as informational RFCs whenever they got  
updated according to the comments.

You have made new comments on Tim's problem statement here. My  
question is one of diminishing returns - would you rather that Tim  
updated the draft (in April) before I sent the thing to Ron, or should  
Ron consider these to be early "IETF last call" comments? If you want  
these handled before sending this to Ron, do you expect to make  
additional comments when he posts that draft? At what point would you  
agree that the problem statement is "close enough"?

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 16 Mar 2009 16:31:51 -0700

At Mon, 16 Mar 2009 11:14:31 -0700,

> Ron consider these to be early "IETF last call" comments? If you want  

I actually don't care, but at least I wouldn't require updating it
before you send it to Ron.  My latest comments are mostly editorial
and (I believe) can be addressed later with IESG comments.

---
JINMEI, Tatuya