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