Subject: [v6ops] WGLC: draft-ietf-v6ops-ipv6-discard-prefix-00

From: Joel jaeggli <[email-masked]>
Date: Mon, 10 Oct 2011 23:14:35 -0700

This message is to initiate a 2 week Working Group Last Call on:

draft-ietf-v6ops-ipv6-discard-prefix-00

available for perusal here:

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-discard-prefix-00

the WGLC runs:

Tuesday the 11TH October 2011 to Tuesday October the 25th 2011.

Commentary or feedback on this recently accepted working group document
which was presented at IETF 81 as
draft-hilliard-v6ops-ipv6-discard-prefix-00 would be greatly appreciated.

previosly
http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix-00

and diff
http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-discard-prefix-00.txt

Thanks
joel

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 11 Oct 2011 23:05:40 +0300

Below are some recommended changes in order to include RTBH routing
(RFC 3882) also.

Abstract

Remote triggered black hole filtering describes a method of
mitigating against denial-of-service attacks by selectively
discarding traffic based on source or destination address. This
document explains why a unique IPv6 prefix should be formally
assigned by IANA for the purpose of facilitating IPv6 remote
triggered black hole filtering.

Remote triggered black hole filtering describes a method of
mitigating against denial-of-service attacks by selectively
discarding traffic based on source or destination address.
Remote triggered black hole routing describes a method
of selectively re-routing traffic into a sinkhole router (for further analysis) based on destination address.
This document explains why a unique IPv6 prefix should be formally
assigned by IANA for the purpose of facilitating IPv6 remote
triggered black hole filtering and routing.

1. Introduction
Remote triggered black hole (RTBH) filtering describes a class of
methods of blocking IP traffic to or from a specific destination on a
network. These methods operate by setting the next-hop address of an
IP packet with a specified source or destination address to be a
unicast prefix which is wired locally or remotely to a router's
discard or null interface. Typically, this information is propagated
throughout an autonomous system using a dynamic routing protocol. By
deploying RTBH systems across a network, traffic to or from specific
destinations may be selectively black-holed in a manner which is
efficient, scalable and straightforward to implement. For IPv4, some
networks configure RTBH installations using [RFC1918] address space
or the address blocks reserved for documentation in [RFC5737].

Remote triggered black hole (RTBH) filtering describes a class of
methods of blocking IP traffic either from a specific source or to a specific destination on a
network. Remote triggered black hole (RTBH) routing describes a class of
methods of re-routing IP traffic destined to the attacked/targeted host to a special path (tunnel) where a sniffer could capture
the traffic for analysis. These methods operate by setting the next-hop address of an
IP packet with a specified source or destination address to be a
unicast prefix which is wired locally or remotely to a router's
discard, null or tunnel interface. Typically, this information is propagated
throughout an autonomous system using a dynamic routing protocol. By
deploying RTBH systems across a network, traffic to or from specific
destinations may be selectively black-holed or re-routed to a sinkhole device in a manner which is
efficient, scalable and straightforward to implement. For IPv4, some
networks configure RTBH installations using [RFC1918] address space
or the address blocks reserved for documentation in [RFC5737].

2. A Discard Prefix for IPv6

For the purposes of implementing an IPv6 remote triggered black hole
filter, a unicast address block is required. There are currently no
IPv6 unicast address blocks which are specifically nominated for the
purposes of implementing RTBH filters.

As [RFC5635] describes situations where more than one discard address
may be used for implementing multiple remote triggered black holes, a

single assigned prefix is not sufficient to cover all likely RTBH
filtering situations. Consequently, an address block is required in
preference to a single address.

For the purposes of implementing an IPv6 remote triggered black
hole

configuration, a unicast address block is required.  There are
currently no

IPv6 unicast address blocks which are specifically nominated
for the

purposes of implementing such RTBH systems.

As [RFC5635] and [RFC3882] describe situations where more than
one discard address

may be used for implementing multiple remote triggered black
hole scenarios, a

single assigned prefix is not sufficient to cover all likely
RTBH

situations.  Consequently, an address block is required in

preference to a single address.

3. Operational Implications

On networks which implement IPv6 remote triggered black holes, some
or all of this network block MAY be configured with a destination of
a discard or null interface on any or all IPv6 routers within the
autonomous system.

On networks which implement IPv6 remote triggered black holes, some
or all of this network block MAY be configured with a destination of
a discard, null or tunnel interface on any or all IPv6 routers within the
autonomous system.

Also a reference to RFC 3882 should be added under "Normative
References".

--
Tassos

Joel jaeggli wrote on 11/10/2011 09:14:

the WGLC runs:

previosly

and diff

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Oct 2011 14:03:35 -0400

LGTM

Support publication, etc.

Must admit that I'm a little sad that we are not requesting something with a cute nemonic like BADC0FFEE or DEADBEEF, but…

W

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Oct 2011 15:43:48 +0200

Hi Tassos,

good suggestions, thanks.  I will revise the ID to take them into account.

Nick

On 11/10/2011 22:05, Tassos Chatzithomaoglou wrote:
> Below are some recommended changes in order to include RTBH routing (RFC
> 3882) also.
> 
>> Abstract
>>    networks configure RTBH installations using [RFC1918 <http://tools.ietf.org/html/rfc1918>] address space
>>    or the address blocks reserved for documentation in [RFC5737 <http://tools.ietf.org/html/rfc5737>].
> 
>    networks configure RTBH installations using [RFC1918 <http://tools.ietf.org/html/rfc1918>] address space
>    or the address blocks reserved for documentation in [RFC5737 <http://tools.ietf.org/html/rfc5737>].
> 
> 
>>    As [RFC5635 <http://tools.ietf.org/html/rfc5635>] describes situations where more than one discard address
>    configuration, a unicast address block is required.  There are currently no
>    As [RFC5635] and [RFC3882] describe situations where more than one
> discard address
>    may be used for implementing multiple remote triggered black hole
> scenarios, a
> 
> Also a reference to RFC 3882 should be added under "Normative References".
> 
> --
> Tassos
> 
> 

-- 
Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | Exchange Association    | Email: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Oct 2011 17:10:23 +0200

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-discard-prefix-00.txt

I'd like to throw a question open to the WG:
draft-ietf-v6ops-ipv6-discard-prefix-00 includes a new security section
which requests that the ipv6 discard prefix be classed as a martian.  This
was put in on the suggestion from a wg member.

Problem is, I don't think we really have a good idea of how a martian is
actually defined.  On a Cisco router, a martian is whatever you define it
to be; most people decide to use rfc3330/rfc5735 in their martian list, and
then apply the martian list to e.g. all ebgp/ibgp sessions.

However on a Juniper router, there is a hard-coded list of martians
pre-defined in Junos software which is based on RFC3330 (which is now
incorrect because 128/16 is no longer listed in rfc5735).  This list is
hidden by default, but you can get a list of black-holed prefixes using
"show route martians".

I can see some situations where you might want to distribute a discard
prefix in your IGP, which immediately means that if Vendor J includes this
sort of prefix in a list of ipv6 martians, it won't immediately work
without explicitly enabling it in the junos martians configuration.

So on reflection, I'm not sure that the new text adds much to the ID.

Does anyone have any opinions on this?  Unless I hear good reasoning to the
contrary, my instinct is to remove the word "martian" and merely state that
under normal circumstances, the discard prefix should not traverse an ASN
boundary.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 17 Oct 2011 08:19:48 -0700

> under normal circumstances, the discard prefix should not traverse an ASN

I think that the language needs to be stronger than that (e.g. the
current language is strong enough but we don't like the term I guess).
As far as I'm concerned unless you want to distribute it your igp it
should be filtered by default.

it's a martian becuase under normal circumstances you should never see
it in your table except as the discard route, never accept traffic from
it etc.

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 17 Oct 2011 18:25:27 +0300

Juniper has already issued the following:
http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2011-10-393&actionBtn=Search

I'd go with martian, although it wouldn't matter to me a lot if not.

Regards,
Tassos

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 19 Oct 2011 09:22:45 -0700

On 10/12/11 11:03 , Warren Kumari wrote:
> Must admit that I'm a little sad that we are not requesting something
> with a cute nemonic like BADC0FFEE or DEADBEEF, but…

that's a discussion one has with IANA, but you don't assign it in the
document.

> W On Oct 11, 2011, at 2:14 AM, Joel jaeggli wrote:
> 
>> Commentary or feedback on this recently accepted working group
>> document which was presented at IETF 81 as 
and diff
Thanks
>> joel _______________________________________________ v6ops mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
>

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 19 Oct 2011 09:23:51 -0700

The halfway point was Tuesday the 18th...

WGLC closes on tuesday the 25th.

Thanks
joel

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 26 Oct 2011 13:00:51 +0100

> was put in on the suggestion from a wg member.
[...]
> under normal circumstances, the discard prefix should not traverse an ASN

3 people replied with suggestions: one yes, one no and one maybe.  So I
have changed the text for this to remove the word "martian".  Problem is,
the term isn't well defined and it means different things to different
people.  This will invariably lead to confusion in future.  The text now
makes a recommendation that the prefix be included in inter-domain bgp
prefix filters because that's what is important.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 26 Oct 2011 21:03:06 -0700

The WGLC concluded on 10/25

I believe that the author has undertaken to commit a version of the
draft with wordsmithing changes discussed during the last call, which
when publish will be noted to the list and submitted to the IESG. I did
not record substantive opposition to this last call.

Thanks
joel

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 28 Oct 2011 21:28:03 +0100

> that's a discussion one has with IANA, but you don't assign it in the

As an adjunct to the current jaw-droppingly bizarre discussion on
[email-masked] about smartypants names, I am now convinced that it is not
just desirable to suggest a cute mnemonic for this prefix, but necessary.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 29 Oct 2011 22:17:24 -0700

> just desirable to suggest a cute mnemonic for this prefix, but necessary.

Prefix Embedded Discard Route Object

I'm just going to hold me head in my hands now...

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 29 Oct 2011 23:12:52 -0700

> prefix filters because that's what is important.

Not that  I have a problem with you changing it, but the term appears in
rfc 3704. and in the internet jargon file (as in a packet not of this
earth) on or before 1990. so if there's confusion with the term it's of
fairly recent origin.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 30 Oct 2011 17:13:53 +0000

> earth) on or before 1990. so if there's confusion with the term it's of

The problem is that the discard prefix that we're talking about here is an
inter-domain martian but not necessarily and interior martian.  Referring
to it as a "martian" and leaving it at that is going to cause long term
confusion.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 30 Oct 2011 16:02:47 -0700

> to it as a "martian" and leaving it at that is going to cause long term

What you do you inside your own context with a prefix with a non-global
(and in this case narrowly defined) scope is your own business.
127.0.0.1/32 is a perfectly valid source address for traffic on a
machine. outside if it not so much.