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

[Tony Tauber <[e-mail]>]

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 <
[e-mail]> 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)!
>> [e-mail]
>>
>>
>>  -----Original Message-----
>>> From: [e-mail] [mailto:[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"<christopher.morrow@**gmail.com<[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>
>