Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 1 Apr 2012 20:01:35 +0200

This is to initiate a two week working group last call of draft-ietf-v6ops-ivi-icmp-address. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Apr 2012 08:38:34 +0200

I've stated previously on this list that I fundamentally disagree with 
this draft. After reviewing the latest text, I continue to hold this 
viewpoint.

For the mechanism in the draft to work, untraceable packets have to be 
allowed across an AS boundary (section 4). It therefore negates the good 
work of BCP84 RFC3704 in mitigating DDoS and other untraceable attacks 
from spoofed addresses.

This untraceable source address range will be abused.

So IHMO, either network operators will filter all traffic from the newly 
assigned shared range, and the draft will not achieve its stated goal, 
or network operators will not filter this traffic, and thus expose 
themselves to being a transit for a DDoS attack that they cannot prove 
was not sourced within their AS. Either way, it will lead to an 
undesirable operational situation (draft not working, or operator 
exposed to untraceable abuse).

The authors have spent considerable effort on defining mitigation 
measures, such as rate limiting at source, but the fact of the matter is 
that bad guys don't obey RFC's, and so the mitigation measures defined 
in the draft will not adequately protect against abuse.

There are also alternatives available to assigning the proposed address 
range: using RFC1918 addresses within an AS, assigning a small range 
from a provider's existing IPv4 allocation, or even sharing assigned 
IPv4 PI address space across multiple providers (with one network 
provider taking the lead in coordinating help desk responses to queries 
upon abuse.) These alternatives are in no way ideal, but they will work, 
and are traceable back to a source/ network abuse help desk.

IPv4 addresses may have run out, but we shouldn't break existing 
implementations and operations.

regards,
RayH

Fred Baker wrote:
> This is to initiate a two week working group last call of 
> draft-ietf-v6ops-ivi-icmp-address. Please read it now. If you find 
> nits (spelling errors, minor suggested wording changes, etc), comment 
> to the authors; if you find greater issues, such as disagreeing with a 
> statement or finding additional issues that need to be addressed, 
> please post your comments to the list.
>
> We are looking specifically for comments on the importance of the 
> document as well as its content. If you have read the document and 
> believe it to be of operational utility, that is also an important 
> comment to make.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Apr 2012 20:52:21 -0400

On Apr 1, 2012, at 2:01 PM, Fred Baker wrote:

> This is to initiate a two week working group last call of draft-ietf-v6ops-ivi-icmp-address.

Phew, just before the cut-off….

> Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

Sure -- I (still) have some serious concerns about this draft...

It is basically proposing something that looks kinda like source address anycast ;-)

I cannot really understand what an operator is expected to do here. As I see it,  there are two options:

Option 1: Simply permit all packets from this address block into the network, with no regard for uRPF, etc.
This options seems like an obvious fail from a DoS / DDoS standpoint -- I'll have no real way to track these back, know which are legitimate, etc and so it will become a standard DoS vector… 

This leaves me with option 2…

Option 2: Simply filter all packets from $MAGIC_BLOCK and drop them on the floor.
Now I am back to where we are currently -- might as well just use RFC1918 space…

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

I believe it to either be of no operational utility (I'll simply filter this block) or actual harm (folk will allow it in, and then it will be used for DoS…

Sorry,
W

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

---

From: "Ramji Vaithianathan (rvaithia)" <[email-masked]>
Date: Thu, 12 Apr 2012 00:25:22 -0700

Regarding Option 1, the draft talks about advertising the special
prefix, so routers can do an uRPF check to ensure that the pkts have a
reverse path to the NAT64 translator which supports this prefix.

Thanks,

Ramji

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Warren Kumari
Sent: Thursday, April 12, 2012 6:22 AM
To: Fred Baker (fred)
Cc: IPv6 Operations; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC

> This is to initiate a two week working group last call of
draft-ietf-v6ops-ivi-icmp-address.

Phew, just before the cut-off....

> Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the list.

It is basically proposing something that looks kinda like source address
anycast ;-)

I cannot really understand what an operator is expected to do here. As I
see it,  there are two options:

Option 1: Simply permit all packets from this address block into the
network, with no regard for uRPF, etc.
This options seems like an obvious fail from a DoS / DDoS standpoint --
I'll have no real way to track these back, know which are legitimate,
etc and so it will become a standard DoS vector... 

This leaves me with option 2...

Option 2: Simply filter all packets from $MAGIC_BLOCK and drop them on
the floor.
Now I am back to where we are currently -- might as well just use
RFC1918 space...

I believe it to either be of no operational utility (I'll simply filter
this block) or actual harm (folk will allow it in, and then it will be
used for DoS...

Sorry,
W

---

From: "George, Wes" <[email-masked]>
Date: Thu, 12 Apr 2012 12:47:42 -0400

I'm opposed to this draft in its current form.

Others have already expressed the concern about a WKP and its security implications, so I won't retread.

I also have misgivings about the effectiveness of managing something like an MTU problem across a translator by expecting networks to carry these translated IPv4 packets from what amounts to an unknown source to convey "packet too big" such that it results in correct behavior more than about half of the time. We can't make this work reliably today (people filtering more ICMP types than they should because "ICMP is bad")! Further, the draft doesn't provide too many other examples of critical ICMP messages that would be needed from end host to end host. Some other examples, along with explanations about why this is the only way to resolve them would go a long way to bolstering the case for this implementation. For example, if we're talking about traces and pings, I don't view this as a robust troubleshooting method - if I get timeouts, how do I know whether there's a problem on the path, or if I've simply strayed into Warren's network and he's decided to block packets with this source address? I'm not sure an enhanced traceroute fixes this.

Ok I lied, I will mention one security problem that I haven't seen mentioned already. I think that there is a potential for a crafted-packet DoS attack on the end user or the gateways. What's to stop an attacker from sending "packet to big" messages sourced from this WKP to the endpoints such that the MTU continues to get reduced and reduced until it's sending out 64-byte packets? Anything under 1280 would require some sort of intervening fragmentation between the IPv6 endpoints (whatever is acting as the "host"), or if you're looking in the opposite direction, would simply create IPv6 packets that have a larger header than data payload (because the original IPv4 packet was 64 bytes), and packets that small create all sorts of nasty problems with things like firewalls, linerate packet forwarding, etc.

I think I like the idea of recommending that the solution to this problem is that the carrier managing this stateless translator MUST provide an IP address or block to be used as the source address for ICMP messages from untranslatable IPv6 addresses. No WKP, just let them allocate one. You could then discuss what the pros and cons are to using 1918 addresses for this purpose vs. a real globally unique address or block. I'm not sure that this method would address the security concerns to everyone's satisfaction either, but I think I'm seeing clear opposition to a WKP.

Thanks,

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Sunday, April 01, 2012 2:02 PM
To: IPv6 Operations
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 12 Apr 2012 11:58:05 -0500

> I think I like the idea of recommending that the solution to this
problem is that
> the carrier managing this stateless translator MUST provide an IP
address or
> block to be used as the source address for ICMP messages from
untranslatable
> IPv6 addresses. No WKP, just let them allocate one.  

+1.

Just follow what 6rd did by letting go WKP and allowing the operator to
allocate one of their own prefixes.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> George, Wes
> Sent: Thursday, April 12, 2012 12:48 PM
> To: Fred Baker (fred); IPv6 Operations
> I also have misgivings about the effectiveness of managing something
like an
> MTU problem across a translator by expecting networks to carry these
> translated IPv4 packets from what amounts to an unknown source to
convey
> "packet too big" such that it results in correct behavior more than
about half of
> the time. We can't make this work reliably today (people filtering
more ICMP
> types than they should because "ICMP is bad")! Further, the draft
doesn't
> provide too many other examples of critical ICMP messages that would
be
> needed from end host to end host. Some other examples, along with
> explanations about why this is the only way to resolve them would go a
long
> way to bolstering the case for this implementation. For example, if
we're
> talking about traces and pings, I don't view this as a robust
troubleshooting
> method - if I get timeouts, how do I know whether there's a problem on
the
> path, or if I've simply strayed into Warren's network and he's decided
to block
> packets with this source address? I'm not sure an enhanced traceroute
fixes
> this.
> 
> 
> 
> Ok I lied, I will mention one security problem that I haven't seen
mentioned
> already. I think that there is a potential for a crafted-packet DoS
attack on the
> end user or the gateways. What's to stop an attacker from sending
"packet to
> big" messages sourced from this WKP to the endpoints such that the MTU
> continues to get reduced and reduced until it's sending out 64-byte
packets?
> Anything under 1280 would require some sort of intervening
fragmentation
> between the IPv6 endpoints (whatever is acting as the "host"), or if
you're
> looking in the opposite direction, would simply create IPv6 packets
that have a
> larger header than data payload (because the original IPv4 packet was
64
> bytes), and packets that small create all sorts of nasty problems with
things like
> firewalls, linerate packet forwarding, etc.
> 
> 
> 
> I think I like the idea of recommending that the solution to this
problem is that
> the carrier managing this stateless translator MUST provide an IP
address or
> block to be used as the source address for ICMP messages from
untranslatable
> IPv6 addresses. No WKP, just let them allocate one. You could then
discuss what
> the pros and cons are to using 1918 addresses for this purpose vs. a
real
> globally unique address or block. I'm not sure that this method would
address
> the security concerns to everyone's satisfaction either, but I think
I'm seeing
> clear opposition to a WKP.
> 
> 
> 
> Thanks,
> 
> 
> 
> Wes George
> 
> 
> 
Of
> Fred Baker
draft-ietf-v6ops-ivi-
> icmp-address. Please read it now. If you find nits (spelling errors,
minor
> suggested wording changes, etc), comment to the authors; if you find
greater
> issues, such as disagreeing with a statement or finding additional
issues that
> need to be addressed, please post your comments to the list.
> 
> 
> 
document
> as well as its content. If you have read the document and believe it
to be of
> operational utility, that is also an important comment to make.
> 
> 
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
to
> copyright belonging to Time Warner Cable. This E-mail is intended
solely for
> the use of the individual or entity to which it is addressed. If you
are not the
> intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to
the contents
> of and attachments to this E-mail is strictly prohibited and may be
unlawful. If
> you have received this E-mail in error, please notify the sender
immediately
> and permanently delete the original and any copy of this E-mail and
any
> printout.

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Apr 2012 10:21:29 -0700

So, let me see if I can summarize the comments so far. I'm going to leave out a lot of detail, and focus on the big picture, and in that I *think* develop a way forward. This is not a pronouncement, it's a question, and what I'm looking for is agreement, disagreement, and additional nuance where needed.

I haven't heard any complaints about using RFC 5837 extensions to identify the actual IPv6 address of a system that is identifying a problem. I have heard that currently-deployed applications may or may not use it effectively, and so it is less useful than it might be.

What I have heard is an issue about using a specified IPv4 address as source in data directed from the translator to an application. Issues raised include BCP 38 issues, operational requirements to advertise an address that is not intended to be used as a destination, and the possibility of attacks on that address.

So, I think the fairest thing we can say is that working group consensus does not support the draft as it stands, and specifically does not support the allocation of a prefix for the purpose. What the working group *might* support is guidance on how best to use RFC 5837 for the purpose.

Your thoughts?

---

From: Warren Kumari <[email-masked]>
Date: Sat, 14 Apr 2012 22:42:42 -0400

> reverse path to the NAT64 translator which supports this prefix.

Yes, you you say this like it's a feature, I via it as a bug…

In a network that peers with a large number of folk I'll see this on a large number of interfaces[0], and so I'll accept packets on all those interfaces -- I understand that that is (from your viewpoint) the Right Thing to do, but you completely seem to be ignoring the DoS problem… The whole point of uRPF is to prevent solo spoofing addresses -- you are proposing a: defeating this protection, and b: providing a prefix tailored for hiding in…

I simply don't want to be accepting a whole heap-o-packets that I cannot trust / do anything with, so my only option would be to simply filter them… 

W

[0]: Assuming this got traction...

---

From: Xing Li <[email-masked]>
Date: Tue, 24 Apr 2012 08:48:18 +0800

Hi, Fred and All,

Thanks for managing the WGLC for draft-ietf-v6ops-ivi-icmp-address WGLC.
Your summary is accurate. Even we think the combination of WKP and 
RFC5837 is a good method, we also fully understand the worries 
concerning the uRPF issues of the WKP. Therefore, we will update this 
draft focusing on the use of public IPv4 address (interface, loopback, 
or even a pool shared by several stateless translators) + RFC5837 and 
looking for the WG review.

Regards,

xing

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Apr 2012 07:54:12 +0200

On Apr 24, 2012, at 2:48 AM, Xing Li wrote:

> Your summary is accurate. Even we think the combination of WKP and RFC5837 is a good method, we also fully understand the worries concerning the uRPF issues of the WKP. Therefore, we will update this draft focusing on the use of public IPv4 address (interface, loopback, or even a pool shared by several stateless translators) + RFC5837 and looking for the WG review.

That seems reasonable.