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 protected]> 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 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 protected] >> >> >> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> t.petch >>> Sent: Friday, June 08, 2012 8:06 AM >>> To: Christopher Morrow; [email protected]; [email protected] >>> 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"<christopher.morrow@**gmail.com<[email protected]> >>> > >>> To:<[email protected]**>;<[email protected]> >>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow> >>>> >>>> >>> ______________________________**_________________ >>> GROW mailing list >>> [email protected] >>> 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 >> [email protected] >> https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow> >> >> >> > > -- > > > ______________________________**_________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/grow<https://www.ietf.org/mailman/listinfo/grow> >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
