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

["Smith, Donald" <[e-mail]>]

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).

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


> -----Original Message-----
> From: Tony Tauber [mailto:[e-mail]]
> Sent: Wednesday, June 13, 2012 6:27 AM
> To: [e-mail]
> Cc: Smith, Donald; [e-mail]; [e-mail]
> Subject: Re: [GROW] WGLC: draft-ietf-grow-private-ip-sp-cores
>
> 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 <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.
>
>       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:
>
>
>               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 <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
>
>               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)!
>               [e-mail]
>
>
>
>
>                       -----Original Message-----
>                       From: [e-mail] [mailto:grow-
> [e-mail]] On Behalf Of
>                       t.petch
>                       Sent: Friday, June 08, 2012 8:06 AM
>                       To: Christopher Morrow; [e-mail];
> [e-mail]
>                       Subject: Re: [GROW] WGLC: draft-ietf-grow-private-ip-
> sp-cores
>
>                       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"<[e-mail]
> <mailto:[e-mail]> >
>                       To:<[e-mail]>;<[e-mail]>
>                       Sent: Tuesday, June 05, 2012 7:41 PM
>
>
>                               Folks,
>                               There's been work on the draft:
>                                  <http://tools.ietf.org/html/draft-ietf-grow-
> private-ip-sp-cores <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
>                               _______________________________________________
>                               GROW mailing list
>                               [e-mail]
>                               https://www.ietf.org/mailman/listinfo/grow
> <https://www.ietf.org/mailman/listinfo/grow>
>
>
>
>
>                       _______________________________________________
>                       GROW mailing list
>                       [e-mail]
>                       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
>               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.
>               _______________________________________________
>               GROW mailing list
>               [e-mail]
>               https://www.ietf.org/mailman/listinfo/grow
> <https://www.ietf.org/mailman/listinfo/grow>
>
>
>
>
>
>
>       --
>
>
>
>       _______________________________________________
>       GROW mailing list
>       [e-mail]
>       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
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.