headers
Fred Baker | 3 Jun 2010 22:35
Picon
Favicon

Fwd: IETF 78 - Meeting and Sponsorship Information


Begin forwarded message:

> From: IETF Secretariat <ietf-secretariat@...>
> Date: June 3, 2010 12:51:40 PM PDT
> To: Working Group Chairs <wgchairs@...>
> Subject: IETF 78 - Meeting and Sponsorship Information 
> 
> Working Group Chairs,
> 
> Can you please forward this message to your individual working group
> emails lists.  We want to ensure that as many people as possible are aware
> of the sponsorship opportunities available at IETF meetings.
> 
> Thank you.
> ==========================================
> 78th IETF Meeting 
> Maastricht, Netherlands
> July 25-30, 2010 
> 
> 1. Sponsorship Opportunities
> 2. Registration Types
> 3. Visas and Letters of Invitation
> 4. Accommodations & Breakfast Information
> 5. IETF 79 (Beijing) Visa Information
> 
> 1) Sponsorship Opportunities
> There are still sponsorship opportunities and benefits for high profile
> company/organizational exposure at the upcoming IETF meeting in
> Maastricht, Netherlands from July 25-30, 2010.  All sponsorship fees go
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ole Troan | 4 Jun 2010 22:24
Picon
Favicon

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-06.txt

this revision is  just fixing a couple of outdated references and nits to get the document advanced.

cheers,
Ole

On Jun 4, 2010, at 17:15 , Internet-Drafts@... wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working Group of the IETF.
> 
> 
> 	Title           : Basic Requirements for IPv6 Customer Edge Routers
> 	Author(s)       : H. Singh, et al.
> 	Filename        : draft-ietf-v6ops-ipv6-cpe-router-06.txt
> 	Pages           : 16
> 	Date            : 2010-06-04
> 
> This document specifies requirements for an IPv6 Customer Edge (CE)
> router.  Specifically, the current version of this document focuses
> on the basic provisioning of an IPv6 CE router and the provisioning
> of IPv6 hosts attached to it.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Chown | 7 Jun 2010 15:49
Picon
Favicon

Re: I-D Action:draft-ietf-v6ops-rogue-ra-01.txt

Hi,

This is purely a version update for administrative purposes.

The only text change is the addition of the word 'helps' in Section 4 to clarify a comment from the security review.

We believe the text is being progressed to Informational alongside Gunter's RA Guard text.

Tim

On 7 Jun 2010, at 14:45, Internet-Drafts@... wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working Group of the IETF.
> 
> 
> 	Title           : Rogue IPv6 Router Advertisement Problem Statement
> 	Author(s)       : T. Chown, S. Venaas
> 	Filename        : draft-ietf-v6ops-rogue-ra-01.txt
> 	Pages           : 16
> 	Date            : 2010-06-07
> 
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Livingood | 7 Jun 2010 16:52
Picon

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-06.txt

Ole - To refresh everyone's memory (or at least my own), what are the next
steps here?  Is this nearing WGLC do you think or are there additional
updates expected?  I searched the mail archive and wasn't sure...

Thanks
Jason 

On 6/4/10 4:24 PM, "Ole Troan" <ot@...> wrote:

> this revision is  just fixing a couple of outdated references and nits to get
> the document advanced.
> 
> cheers,
> Ole
> 
> 
> On Jun 4, 2010, at 17:15 , Internet-Drafts@... wrote:
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IPv6 Operations Working Group of the IETF.
>> 
>> 
>> Title           : Basic Requirements for IPv6 Customer Edge Routers
>> Author(s)       : H. Singh, et al.
>> Filename        : draft-ietf-v6ops-ipv6-cpe-router-06.txt
>> Pages           : 16
>> Date            : 2010-06-04
>> 
>> This document specifies requirements for an IPv6 Customer Edge (CE)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fred Baker | 7 Jun 2010 18:51
Picon
Favicon

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-06.txt

I am about to mail it in.

On Jun 7, 2010, at 7:52 AM, Jason Livingood wrote:

> Ole - To refresh everyone's memory (or at least my own), what are the next
> steps here?  Is this nearing WGLC do you think or are there additional
> updates expected?  I searched the mail archive and wasn't sure...
> 
> Thanks
> Jason 
> 
> 
> On 6/4/10 4:24 PM, "Ole Troan" <ot@...> wrote:
> 
>> this revision is  just fixing a couple of outdated references and nits to get
>> the document advanced.
>> 
>> cheers,
>> Ole
>> 
>> 
>> On Jun 4, 2010, at 17:15 , Internet-Drafts@... wrote:
>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the IPv6 Operations Working Group of the IETF.
>>> 
>>> 
>>> Title           : Basic Requirements for IPv6 Customer Edge Routers
>>> Author(s)       : H. Singh, et al.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale W. Carder | 8 Jun 2010 23:24
Picon
Favicon
Gravatar

RFC 5006 and draft-ietf-v6ops-rogue-ra-01

In the latest version of draft-ietf-v6ops-rogue-ra-01, section
5.5 talks about recovering from an invalid configuration state
w.r.t. the M & O bits.  

Should the document also mentioned that the host may also have 
incorrect, non-functional, or potentially malicious DNS 
configuration due to the host believing bogus RFC 5006 
advertisements?  The host may also need to recover from this
as well.

Dale
Permalink | Reply | 0 comments |
headers
Tim Chown | 9 Jun 2010 15:28
Picon
Favicon

Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01


On 8 Jun 2010, at 22:24, Dale W. Carder wrote:

> In the latest version of draft-ietf-v6ops-rogue-ra-01, section
> 5.5 talks about recovering from an invalid configuration state
> w.r.t. the M & O bits.  
> 
> Should the document also mentioned that the host may also have 
> incorrect, non-functional, or potentially malicious DNS 
> configuration due to the host believing bogus RFC 5006 
> advertisements?  The host may also need to recover from this
> as well.

So that's a good question.    When the rogue RA draft was first written, RFC5006 was I recall itself a draft in
its infancy.     It's pretty clear that a rogue RA may also be an RA with 'bad' DNS resolver information in it.

We could add text about this.   That would involve some mention of the problem in Section 1 (introduction),
perhaps a brief discussion as an extra point in Section 5, and adding the mitigation mentioned in
draft-ietf-6man-dns-options-bis-02 of disabling the host from processing DNS options in the RA
(assuming the host implementation supports that of course, which isn't a MUST in the draft as far as I can
see).   Other than that, I think the text in the draft about rogue RA 'badness' is generic enough to cover bad
DNS information.   I'm happy to work with Stig on such text if it's deemed useful, and won't hold up
publication too much more.

I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to
the rogue RA draft in its own security discussion, and also no mention of RA Guard.

Tim
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roque Gagliano | 10 Jun 2010 11:15
Picon
Favicon

Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01

Hi Tim,

> We could add text about this.   That would involve some mention of the problem in Section 1 (introduction),
perhaps a brief discussion as an extra point in Section 5, and adding the mitigation mentioned in
draft-ietf-6man-dns-options-bis-02 of disabling the host from processing DNS options in the RA
(assuming the host implementation supports that of course, which isn't a MUST in the draft as far as I can
see).   Other than that, I think the text in the draft about rogue RA 'badness' is generic enough to cover bad
DNS information.   I'm happy to work with Stig on such text if it's deemed useful, and won't hold up
publication too much more.
> 
> I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to
the rogue RA draft in its own security discussion, and also no mention of RA Guard.
> 

Why would the dns-option be different from any other ICMPv6 option in this draft context? I would keep the
text generic on reference to ICMP options.

Roque

> Tim
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 1 comment |
headers
Roque Gagliano | 10 Jun 2010 11:26
Picon
Favicon

Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01

Sorry,

I should have said NDP options and not ICMPv6 options.

Roque.

On Jun 10, 2010, at 11:15 AM, Roque Gagliano wrote:

> Hi Tim,
> 
>> We could add text about this.   That would involve some mention of the problem in Section 1 (introduction),
perhaps a brief discussion as an extra point in Section 5, and adding the mitigation mentioned in
draft-ietf-6man-dns-options-bis-02 of disabling the host from processing DNS options in the RA
(assuming the host implementation supports that of course, which isn't a MUST in the draft as far as I can
see).   Other than that, I think the text in the draft about rogue RA 'badness' is generic enough to cover bad
DNS information.   I'm happy to work with Stig on such text if it's deemed useful, and won't hold up
publication too much more.
>> 
>> I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to
the rogue RA draft in its own security discussion, and also no mention of RA Guard.
>> 
> 
> Why would the dns-option be different from any other ICMPv6 option in this draft context? I would keep the
text generic on reference to ICMP options.
> 
> Roque
> 
>> Tim
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 10 Jun 2010 14:33
Picon
Favicon

Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01

Hi Roque,

The draft is focused on rogue RAs as that has been an operational issue for us in our dual-stack enterprise
for quite some time.   The potential for additional forms of 'badness' to come from RA-based DNS
configuration are worth noting, but the mitigations in general are the same.     There may be some additional
mitigation methods specific to the DNS option/configuration.

While we do run tools to detect various forms of NDP 'abuse' on our network, e.g. use of the THC toolkit, we
don't (yet) see evidence of that.    The rogue RA problem is far more heavily observed and cited and thus
having a consolidated informational problem statement that also describes some potential mitigations
focused on that problem is, we believe, useful.   Malicious rogue RAs are quite rare - ones caused by Windows
ICS, accidental misconfiguration or devices being moved where their role changes (e.g. 6to4 router at
home, client at work) are far more common.   But then we're in a CS dept, so our users tend to be more 'creative'.

We released ramond (http://ramond.sourceforge.net/) as an enhancement to rafixd as one tool for people
to use.   RA Guard also has good potential.

Tim

On 10 Jun 2010, at 10:26, Roque Gagliano wrote:

> Sorry,
> 
> I should have said NDP options and not ICMPv6 options.
> 
> Roque.
> 
> On Jun 10, 2010, at 11:15 AM, Roque Gagliano wrote:
> 
>> Hi Tim,
(Continue reading)

Permalink | Reply | 2 comments |

Gmane