Subject: Initial agenda for IETF 71

From: Fred Baker <[email-masked]>
Date: Mon, 11 Feb 2008 10:04:03 -0800

FYI. I asked for two sessions, one of 2.5 and one of 2 hours, and got  
two 2-hour sessions.

> V6OPS Session 1 (2.5 hours)
> Tuesday, Afternoon Session I 1300-1500
> Room Name: Breakout Room
> ----------------------------------------------
> V6OPS Session 2 (2 hours)
> Wednesday, Morning Session I 0900-1130
> Room Name: Breakout Room
> ----------------------------------------------

The agenda items include the following. Note that I include a couple  
of drafts for which I have been promised updates (this week for -00,  
by next week otherwise). I would recommend reading these in advance,  
so that the discussion is fruitful.

Tuesday: transition session
   Key objective: nail down transition expectations/requirements
     draft-jcurran-v6transitionplan
     draft-bagnulo-v6ops-6man-nat64-pb-statement
     draft-stenberg-v6ops-pd-route-maintenance

     draft-durand-v6ops-natv4v6v4
     draft-despres-v6ops-6rd-ipv6-rapid-deployment
     Iljitsch and Brian's merged proposal
     draft-miyata-v6ops-snatpt
     draft-miyata-v6ops-trans-approach

Wednesday: general session
   Brian Dickson's suggestions
     draft-dickson-v6ops-aggregation
     draft-dickson-v6ops-assignment

   The RA discussion
     draft-chown-v6ops-rogue-ra if Tim updates it
     draft-vandevelde-v6ops-ra-guard

   CPE question
     Gunter's not-yet-submitted CPE-default-route-detection
     draft-ietf-v6ops-cpe-simple-security

- -----------------------------------------------------
I did not include the two Teredo updates:
     draft-ietf-v6ops-teredo-security-concerns
     draft-krishnan-v6ops-teredo-update

Since we are discussing these in v6ops, I am waiting for an update to  
the security-concerns document, and then will ask for last call  
comments on both. The "Teredo Update" may be sponsored by Mark  
Townsley, who sponsored Teredo.

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Feb 2008 14:14:14 -0500

On 11-Feb-2008, at 13:04, Fred Baker wrote:

> FYI. I asked for two sessions, one of 2.5 and one of 2 hours, and  
> got two 2-hour sessions.
>

This one says 2.5 hours, but the times indicate 2 hours...

... and this one says 2 hours, but the times indicate 2.5. Your note  
at the top of the quoted session says "two 2-hour sessions".

So I'm confused :-)

Joe

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Feb 2008 11:33:37 -0800

> So I'm confused :-)

The obvious question has been placed to agenda@. I asked for, and  
would prefer, 2.5 hours for the transition session - at 15 minutes  
per topic, it's pretty full. Stay tuned.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Feb 2008 21:15:27 +0100

On 11 feb 2008, at 19:04, Fred Baker wrote:

> by next week otherwise).

Note that according to:

http://www.ietf.org/meetings/71-cutoff_dates.html

the -00 cutoff isn't until monday:

February 18, Monday - Internet Draft Cut-off for initial document  
(-00) submission by 17:00 ET (22:00 UTC/GMT), upload using IETF ID  
Submission Tool.

>    Iljitsch and Brian's merged proposal

The new name is draft-v6ops-van-beijnum-mnat-pt-00

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 11 Feb 2008 20:46:45 -0800

Hi Fred,

I have a draft which I would want to be presented. It is the 6PE-Alt
draft which was recently discussed on this list.

http://www.ietf.org/internet-drafts/draft-manral-idr-mpls-explicit-null-00.txt

One of my colleague Samita will be there in the IETF and she will be
able to present it. Is there a way I can get a slot for the same.

Thanks,
Vishwas

On Feb 11, 2008 10:04 AM, Fred Baker <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFHsI4TbjEdbHIsm0MRAg+uAKCoXkdaqE5zCFApX9QowDLLidiVwQCg3PiR
> dwuHvAyePEzRKrCUpy8zRvA=
> =rD1x
> -----END PGP SIGNATURE-----
>
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 12 Feb 2008 14:51:20 +0000

(subject line updated)

>     draft-vandevelde-v6ops-ra-guard

Hi,

On the rogue RA problem statement, Stig and I don't feel there is much
point in an update at this stage, and also that presenting the same
issue for a 3rd time would be beneficial.
 
Looking back on IETF70 minutes (I wasn't there) they say:
	http://tools.ietf.org/wg/v6ops/minutes

which boils down to 'use SEND' on one hand, and some support from 
Iljitsch and Francis on the other.

We're seeing more instances of the problem being reported, e.g. on the
Internet2 list yesterday as a result of the Joint Techs meeting.

We're seeing the problem resurface on our own network (some 1500 dual-stack
hosts on wired and wireless access).   The most recent last week was a 
Vista machine that somehow didn't pick up the real online RA, and chose
to become a 6to4 router as a result (apparently... we'll try to recreate
this one).

I think there's various underlying issues here.

1) Not everyone will deploy SEND, in fact maybe very few networks will.
It would be useful for some SEND fud to perhaps be wiped away, since at
present it seems 'up there' with Authenticated DHCP for deployment as
far as the people I ask reply.

2) Rogue RAs can happen for various accidental or malicious reasons, so
monitoring your link for 'bad' RAs is prudent regardless.   We've looked
at rafixd and are working on some improvements to that as a monitoring
and possibly corrective tool.    This can be rolled into monitoring as 
per ndpmon, perhaps.   So these are new things that should be detectable.

3) There are 'simple' fixes that could be made available today, e.g. a
switch option to en/disable RAs inbound per switch/stack or per port,
which would help just as MLD snooping can do, or DHCP blocking today.

4) The issues with RAs are why people seem keen to use DHCPv6, and the
same people do ask about DHCPv6 default router options (regardless of
the (lack of) security with DHCPv6 itself).

Now, I think (4) is contentious but there could be progress on (1)-(3).

Anyway, perhaps the list could guide on updates to the problem statement,
and what it says (loosely) about solution spaces.

Obviously Gunter is working a little separately on RA Guard as one
possible solution.

-- 
Tim

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 12 Feb 2008 16:54:43 +0100 (CET)

> which would help just as MLD snooping can do, or DHCP blocking today.

For this one we proposed with Gunter in draft-vandevelde-v6ops-ra-guard.

> the (lack of) security with DHCPv6 itself).

Currently the DHCPv6 is rather loosely integrated in most of the operating 
systems....

Maybe one option would be combining the two drafts....

Best Regards,
 		Janos

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Feb 2008 08:21:27 -0800

> and what it says (loosely) about solution spaces.

wfm. thanks.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Feb 2008 09:17:23 -0800

> Currently the DHCPv6 is rather loosely integrated in most of the
> operating systems....

It would be interesting to compare practical solutions to "Rogue RA" and "DHCPv6 spoofing". Is one harder than the other, and why?

-- Christian Huitema

---

From: "Deepak Bansal (NETWORKING)" <[email-masked]>
Date: Tue, 12 Feb 2008 11:27:50 -0800

>The most recent last week was a

Vista will not become a 6to4 router unless ICS is enabled on it. Hence, I suspect that the Vista machine in discussion here somehow had ICS enabled on it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mohacsi Janos
Sent: Tuesday, February 12, 2008 7:55 AM
To: Tim Chown
Cc: [email-masked]
Subject: Re: rogue RA problem statement

Best Regards,
                Janos

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 12 Feb 2008 22:19:16 +0200

Le Tuesday 12 February 2008 21:27:50 Deepak Bansal (NETWORKING), vous avez 
écrit :
> Vista will not become a 6to4 router unless ICS is enabled on it. Hence, I
> suspect that the Vista machine in discussion here somehow had ICS enabled
> on it.

I don't know how easy or difficult or manually or automatically enabling ICS 
is, but on a sizable (1000+) university with public IPv4 addresses, that has 
been a recurrent problem ever since we've provided IPv6 (4 years from now or 
so). Vista "IPv6-on-by-default" did not really help since then. Still, XP SP2 
is the by far the worst, has the built-in firewall blocks incoming RA while 
booting up. Then the PC decides there is no IPv6 router (even though there 
*is*), and turns on 6to4 gatewaying.

Anyway, upgrading the switches to do some filtering is not an option. Using 
SEND is not an option, especially as it's currently not supported by anything 
on the market. So it looks like, for the foreseeable future, reactive "0 
lifetime" RA fixups will remain the only solution. As long as none of the 
automatic 6to4 gateways are doing UNICAST Router Advertisement, it works, 
even though it's an ugly hack.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Tue, 12 Feb 2008 18:40:52 -0500

Adding a few points to those mentioned by Janos ... <c></c> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mohacsi Janos
Sent: Tuesday, February 12, 2008 10:55 AM
To: Tim Chown
Cc: [email-masked]
Subject: Re: rogue RA problem statement

> Vista machine that somehow didn't pick up the real online RA, and 
> chose to become a 6to4 router as a result (apparently... we'll try to 
> recreate this one).
>
> It would be useful for some SEND fud to perhaps be wiped away, since 
> at present it seems 'up there' with Authenticated DHCP for deployment 
> as far as the people I ask reply.
>

<c>
The solutions proposed are not intended to replace SEND but rather
complement it wherever possible. I think that, if nothing else, the
RA-guard options would help SEND in securing a varied set of
environments and deployments.
</c>

> per ndpmon, perhaps.   So these are new things that should be
detectable.

<c>
This is part of some of the solutions proposed by Gunter's draft. It
could however be extended to have devices just monitor and report rather
than take action.

Best Regards,
Chip
</c>

Best Regards,
 		Janos

---

From: John Curran <[email-masked]>
Date: Tue, 12 Feb 2008 18:58:51 -0500

>    draft-stenberg-v6ops-pd-route-maintenance

Fred - I'm in town through Tuesday evening, so if you can
spare 10 minutes or so on the Tuesday agenda, I'd be quite
happy to present the impetus behind the draft.

/John

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Feb 2008 17:47:12 -0800

Outstanding. Thanks.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 14 Feb 2008 12:49:21 +0100

Inline: GV>

> Le Tuesday 12 February 2008 21:27:50 Deepak Bansal (NETWORKING), vous avez écrit :
> > >chose  to become a 6to4 router as a result (apparently... we'll try 
> > >to recreate  this one).
> >
> > Vista will not become a 6to4 router unless ICS is enabled on it. 
> > Hence, I suspect that the Vista machine in discussion here somehow had 
> > ICS enabled on it.

> I don't know how easy or difficult or manually or automatically enabling ICS is, but on a sizable (1000+) university > > with public IPv4 addresses, that has been a recurrent problem ever since we've provided IPv6 (4 years from now or so). > Vista "IPv6-on-by-default" did not really help since then. Still, XP SP2 is the by far the worst, has the built-in 
> firewall blocks incoming RA while booting up. Then the PC decides there is no IPv6 router (even though there *is*), and 
> turns on 6to4 gatewaying.

> Anyway, upgrading the switches to do some filtering is not an option. 

GV> this statement could be correct for the problem that XP SP2 experienced. 
GV> In other cases however filtering RA will however be a simple solution 
GV> for devices that behave according specification, as for example CPE routers attached to an access network of an ISP.
GV> I have real SP asking for RA-Guard like capability in their access networks for IPv6.
GV> SeND will not be deployed their for a long time for many reasons and hence RA-Guard behaviour 
GV> at local access-network switches is an elegant solution. 
GV> (I just don't buy the statement that SeND will solve their needs any time soon, if ever)

GV> Rogue-RA's is something that we should not avoid. It is a reality NOW, and will be for next 
GV> few years when v6 gets deployed further. We better understand the issue, so correct action 
GV> can be taken. Simply claiming SeND will solve 'all' is a bit academic I suspect. It can solve 
GV> certain aspects, but 'not all rogue-RA' issues in 'all environments'.

> Using SEND is not an option, especially as it's currently not supported by anything on the market. 

GV> this is next to the question of solving the root issue. Root issue is not related to SeND.

> So it looks like, 
> for the foreseeable future, reactive "0 lifetime" RA fixups will remain the only solution. As long as none of the > 
> automatic 6to4 gateways are doing UNICAST Router Advertisement, it works, even though it's an ugly hack.

GV> yes, but it is the practical consequence of a host implementation

G/