Subject: [GROW] WGLC: draft-ietf-grow-private-ip-sp-cores

From: Christopher Morrow <[email-masked]>
Date: Tue, 5 Jun 2012 14:41:39 -0400

Folks,
There's been work on the draft:
   <http://tools.ietf.org/html/draft-ietf-grow-private-ip-sp-cores>

I think the commenters' comments were addressed by the authors.
Can we move this to WGLC now and clear that 6/19/2012 (June 19, 2012).

Abstract of the draft:
  "The purpose of this document is to provide a discussion of the
   potential problems of using private, RFC1918, or non-globally-
   routable addressing within the core of an SP network.  The discussion
   focuses on link addresses and to a small extent loopback addresses.
   While many of the issues are well recognised within the ISP
   community, there appears to be no document that collectively
   describes the issues."

Could there be some discussion on WGLC and  we'll see about  moving
this along to the IESG?

-chris

---

From: t.petch <[email-masked]>
Date: Fri, 8 Jun 2012 15:06:16 +0100

I would like to see this published as an RFC.

The only discussion I see whether or not the title of 12.2 should have
an initial capital - I think that it should.

Tom Petch

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 05, 2012 7:41 PM
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 8 Jun 2012 13:08:33 -0400

> I would like to see this published as an RFC.

thanks, I don't disagree.

> an initial capital - I think that it should.

that seems like something that can get cleaned up by the editor if it
comes to it...

would be nice if more folk would chime in, however, in either the
positive or negative.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 08 Jun 2012 18:10:22 +0100

> would be nice if more folk would chime in, however, in either the

+1

---

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Jun 2012 14:34:22 -0400

> I would like to see this published as an RFC.

Yah, me too…

W

-- 
With Feudalism, it's your Count that votes.

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 8 Jun 2012 15:17:45 -0600

There is a mention of "squat" space that doesn't make any recommendations as to use or not.

I can understand not expressing an opinion on the rfc1918/private space shouldn't this state that squating is bad?
"This effect in itself is often not a problem.  However, if anti-
   spoofing controls are applied at network perimeters, then responses
   returned from hops with private IP addresses will be dropped."

Any rfc1918 filtering mechinisim will cause this issue not just bcp38 type anti-spoofing.
Firewalls, junipers and many platforms drop rfc1918 space but not as part of bcp38 .
BTW BCP84 ala rfc3704 is an update/addition to bcp38 you should probably add them to this reference.

And for consistecy I recommend using an expression such as "any rfc1918 or bogon filtering..."

Under section 4 the author says urpf or ingress filtering.
"If the router's interface address is a
   private IP address, then this ICMP reply packet may be discarded due
   to uRPF or ingress filtering, thereby causing the PMTUD mechanism to
   fail."

Under
5. Unexpected interactions with some NAT implementations
The first section works. As stated it might confuse someone but honestly unless the 4th hop also matches the 2 hop it doesn't look like a routing loop to me. It looks like rfc1918 reuse.

Type escape sequence to abort.
   Tracing the route to 198.51.100.100

     1 10.1.1.2 0 msec 0 msec 0 msec
     2 198.51.100.13 0 msec 4 msec 0 msec
     3 10.1.1.2 0 msec 4 msec 0 msec        <<<<
     4 198.51.100.5 4 msec 0 msec 4 msec
     5 198.51.100.1 0 msec 0 msec 0 msec

Section 6 references rfc2827 should probably include bcp84 and rfc3704.

Your first example of a security gap is really a no worse if you use private or public addresss but you call that out so I am ok with it.

NIT
This:
Some applications discover the outside address of
   their local CPE to determine if that address is reserver for special
   use.
Should be this:
Some applications discover the outside address of
   their local CPE to determine if that address is reserved for special
   use.

When packets collide the controllers cease transmission AND wait a random time before retransmission (mostly)!
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> t.petch
> Sent: Friday, June 08, 2012 8:06 AM
> To: Christopher Morrow; [email-masked]; [email-masked]
> Subject: Re: [GROW] WGLC: draft-ietf-grow-private-ip-sp-cores
>

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 11 Jun 2012 10:36:33 -0400

I support publishing. I have brought up concerns around some overlap with another draft, however I believe that this document is far more complete than draft-behringer-lla-only, and can stand on its own.

Thanks,

Wes George

> Warren Kumari
> Sent: Friday, June 08, 2012 2:34 PM
> To: t.petch
> Cc: [email-masked]; [email-masked]
> Yah, me too...

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: Shishio Tsuchiya <[email-masked]>
Date: Tue, 12 Jun 2012 11:18:52 +0900

> I would like to see this published as an RFC.

+1 I support publishing.

Regards,
-Shishio

> From: "Christopher Morrow"<[email-masked]>
> To:<[email-masked]>;<[email-masked]>

---

From: Anthony Kirkham <[email-masked]>
Date: Wed, 13 Jun 2012 20:58:50 +1000

Donald,

Thanks for the review, I plan to do another update in the next few days, 
I'm just waiting to see if any further feedback arrives.

A couple of specific comments:

re - squat space. The intent was not to make recommendations on the 
practice, just to document the effects.

re - 5. Unexpected interactions with some NAT implementations: What you 
say is exactly what I intended to illustrate. I will update the wording 
so its clear I'm not talking about a routing loop.

Regards
Tony K

On 9/06/12 7:17 AM, Smith, Donald wrote:
>       3 10.1.1.2 0 msec 4 msec 0 msec<<<<

--

---

From: Tony Tauber <[email-masked]>
Date: Wed, 13 Jun 2012 08:27:11 -0400

Using squat/stolen space will mean ICMP messages from the SP core wouldn't
be able to reach the legitimate address holder's network but neither would
traffic of the customers of that SP.  I don't believe that the same is true
of "private" space; so there are actually _more_ problems with the "squat"
approach.

In general, big fan, support publication.

Thanks,

Tony T.

On Wed, Jun 13, 2012 at 6:58 AM, Anthony Kirkham <
[email-masked]> wrote:

> say is exactly what I intended to illustrate. I will update the wording so
> its clear I'm not talking about a routing loop.
>
> Regards
> Tony K
>
>
>> I can understand not expressing an opinion on the rfc1918/private space
>> shouldn't this state that squating is bad?
>> The first section works. As stated it might confuse someone but honestly
>> unless the 4th hop also matches the 2 hop it doesn't look like a routing
>> loop to me. It looks like rfc1918 reuse.
>>
>>
>> Your first example of a security gap is really a no worse if you use
>> private or public addresss but you call that out so I am ok with it.
>>
>> NIT
>> This:
>>> Subject: Re: [GROW] WGLC: draft-ietf-grow-private-ip-sp-**cores
>>>
>>> From: "Christopher Morrow"<christopher.morrow@**gmail.com<[email-masked]>
>>> >
>>> To:<[email-masked]**>;<[email-masked]>
>>>>    <http://tools.ietf.org/html/**draft-ietf-grow-private-ip-sp-**cores<http://tools.ietf.org/html/draft-ietf-grow-private-ip-sp-cores>
>>>> >
>>>>
>>>> Can we move this to WGLC now and clear that 6/19/2012 (June 19,
>>>>
>>> 2012).
>>>
>>>> Abstract of the draft:
>>>>    routable addressing within the core of an SP network.  The
>>>>
>>> discussion
>>>
>>>>    focuses on link addresses and to a small extent loopback
>>>>
>>> addresses.
>>>
>>>> ______________________________**_________________
>>>> GROW mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow>
>>>>
>>>>
>>> ______________________________**_________________
>>> GROW mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow>
>>>
>> This communication is the property of CenturyLink and may contain
>> confidential or privileged information. Unauthorized use of this
>> communication is strictly
>> ______________________________**_________________
>> GROW mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow>
>>
>>
>>
>
> --
>
>
> ______________________________**_________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow>
>

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 13 Jun 2012 07:56:41 -0600

Your welcome. I understand not taking a stance on use of priv addresses in the core. I would rather either pull the mention of squat space or recommend against it or explain why it is different then the use of private space. There are elements where that is much worse then the use of rfc1918 space.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: Anthony Kirkham [[email-masked]]
Sent: Wednesday, June 13, 2012 4:58 AM
To: Smith, Donald
Cc: 't.petch'; 'Christopher Morrow'; [email-masked]'; [email-masked]'
Subject: Re: [GROW] WGLC: draft-ietf-grow-private-ip-sp-cores

Donald,

Regards
Tony K

--

________________________________

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 13 Jun 2012 10:18:25 -0600

Exactly! Sorry if I wasn't clear but squatting should be heavily discouraged as many things break that don't break with the use of private space. If you use squatted space you have to do prefix limiting possibly limiting the valid owner from announcing their route(s) to you (or play other better route metrics games).

> From: Tony Tauber [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2012 6:27 AM
> To: [email-masked]
> Cc: Smith, Donald; [email-masked]; [email-masked]
> Using squat/stolen space will mean ICMP messages from the SP core
> wouldn't be able to reach the legitimate address holder's network but
> neither would traffic of the customers of that SP.  I don't believe
> that the same is true of "private" space; so there are actually _more_
> problems with the "squat" approach.
>
> On Wed, Jun 13, 2012 at 6:58 AM, Anthony Kirkham <tkirkham@anthony-
> kirkham.com> wrote:
>
>
>       Donald,
>
>       Thanks for the review, I plan to do another update in the next
> few days, I'm just waiting to see if any further feedback arrives.
>
>       re - squat space. The intent was not to make recommendations on
> the practice, just to document the effects.
>
>       re - 5. Unexpected interactions with some NAT implementations:
> What you say is exactly what I intended to illustrate. I will update
> the wording so its clear I'm not talking about a routing loop.
>
>       Regards
>       Tony K
>
>
>               I can understand not expressing an opinion on the
> rfc1918/private space shouldn't this state that squating is bad?
>               BTW BCP84 ala rfc3704 is an update/addition to bcp38 you
> should probably add them to this reference.
>
>
>               The first section works. As stated it might confuse someone
> but honestly unless the 4th hop also matches the 2 hop it doesn't look
> like a routing loop to me. It looks like rfc1918 reuse.
>
>
>                    3 10.1.1.2 0 <tel:3%2010.1.1.2%200>  msec 4 msec 0
> msec<<<<
>                    4 198.51.100.5 <tel:4%20198.51.100.5>  4 msec 0 msec 4
> msec
>                    5 198.51.100.1 <tel:5%20198.51.100.1>  0 msec 0 msec 0
> msec
>
>               Your first example of a security gap is really a no worse
> if you use private or public addresss but you call that out so I am ok
> with it.
>
>               NIT
>               This:
>               When packets collide the controllers cease transmission AND
> wait a random time before retransmission (mostly)!
>                       From: "Christopher
> Morrow"<[email-masked]
> <mailto:[email-masked]> >
>                                  <http://tools.ietf.org/html/draft-ietf-grow-
> private-ip-sp-cores <http://tools.ietf.org/html/draft-ietf-grow-
> private-ip-sp-cores> >
>
> <https://www.ietf.org/mailman/listinfo/grow>
>
>
>
>
> <https://www.ietf.org/mailman/listinfo/grow>
>
>
>               This communication is the property of CenturyLink and may
> contain confidential or privileged information. Unauthorized use of
> this communication is strictly
> <https://www.ietf.org/mailman/listinfo/grow>
>
>
>
>
>
>
>       --
>
>
>
> <https://www.ietf.org/mailman/listinfo/grow>
>
>

---

From: Anthony Kirkham <[email-masked]>
Date: Sun, 17 Jun 2012 14:39:05 +1000

Tony and Donald,

What say If I change the wording on squat space from:

"The practice of ISPs using 'stolen' address space (also known as 
'squat' space) has many of the same issues (or effects) as that of using 
private IP address space within core networks.", plus some additional

  to:

"The practice of ISPs using 'stolen' address space (also known as 
'squat' space) has many of the same, plus some additional issues (or 
effects) as that of using private IP address space within core networks."

Regards
Tony K

On 13/06/12 10:27 PM, Tony Tauber wrote:
> On Wed, Jun 13, 2012 at 6:58 AM, Anthony Kirkham 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Donald,
>
>     Thanks for the review, I plan to do another update in the next few
>     days, I'm just waiting to see if any further feedback arrives.
>
>     What you say is exactly what I intended to illustrate. I will
>     update the wording so its clear I'm not talking about a routing loop.
>
>     Regards
>     Tony K
>
>
>         but honestly unless the 4th hop also matches the 2 hop it
>         doesn't look like a routing loop to me. It looks like rfc1918
>         reuse.
>
>
>         3 10.1.1.2 0 <tel:3%2010.1.1.2%200> msec 4 msec 0 msec<<<<
>         4 198.51.100.5 <tel:4%20198.51.100.5> 4 msec 0 msec 4 msec
>         5 198.51.100.1 <tel:5%20198.51.100.1> 0 msec 0 msec 0 msec
>
>         Your first example of a security gap is really a no worse if
>         you use private or public addresss but you call that out so I
>         am ok with it.
>
>         NIT
>         This:
>             From: [email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of
>             t.petch
>             To: Christopher Morrow; [email-masked]
>             <mailto:[email-masked]>; [email-masked]
>             <mailto:[email-masked]>
>             From: "Christopher Morrow"<[email-masked]
>             <mailto:[email-masked]>>
>             To:<[email-masked]
>             <mailto:[email-masked]>>;<[email-masked]
>             <mailto:[email-masked]>>
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         contain confidential or privileged information. Unauthorized
>         use of this communication is strictly
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

--

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 27 Jun 2012 14:26:52 -0400

> Can we move this to WGLC now and clear that 6/19/2012 (June 19, 2012).

While it's long past this date, I haven't seen a note saying that the WGLC
concluded successfully.  So, I'll add in my support for publication FWIW.

-- Jeff

---

From: Anthony Kirkham <[email-masked]>
Date: Sat, 30 Jun 2012 11:11:16 +1000

> concluded successfully.  So, I'll add in my support for publication FWIW.
Jeff,

Thank you for your support. I'm hoping this gets closed off soon.

Tony K

--