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

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)!
> Donald.Smith@CenturyLink.com
>
>
>> -----Original Message-----
>> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of
>> t.petch
>> Sent: Friday, June 08, 2012 8:06 AM
>> To: Christopher Morrow; grow-chairs@tools.ietf.org; grow@ietf.org
>> 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>
>> To:<grow-chairs@tools.ietf.org>;<grow@ietf.org>
>> 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>
>>>
>>> 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
>>> GROW@ietf.org
>>> https://www.ietf.org/mailman/listinfo/grow
>>>
>>
>> _______________________________________________
>> GROW mailing list
>> GROW@ietf.org
>> 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
>

-- 