Subject: Re: [GROW] Final feedback please - kirkham-private-ip-sp-cores

From: Anthony Kirkham <[email-masked]>
Date: Wed, 05 Oct 2011 10:24:28 +1000

George,

I have updated the draft with the extra example as you suggested. I do 
believe this adds to the clarity.

I made note of the term 'squat space'.

I have not included discuss of implications for an IS-IS hidden core. I 
agree with your comments, however, I thought that discussion was moving 
a little away from the core topic.

A new draft has been posted:

Filename:	 draft-kirkham-private-ip-sp-cores
Revision:	 07
Title:		 Issues with Private IP Addressing in the Internet
Creation date:	 2011-10-05
WG ID:		 Individual Submission
Number of pages: 14

Regards
Tony K

On 1/10/11 2:58 AM, George, Wes wrote:
>
> I might note that the more common term for what you're calling 
> "stolen" address space is squat space, but that's a minor nit at best.
>
> Also, I think it's important to make a distinction between setups 
> where there are no global addresses on a given router at all  vs 
> situations where the router has one or more loopbacks or other 
> interfaces which are publicly routable, but the individual PTP 
> interfaces are using 1918 space (or are configured with "unnumbered"). 
> I think that this is equally uncommon within a tier-1 ISP, but some of 
> the accompanying problems can be managed better with configuration 
> tweaks to force the box to use a certain source address for "from us" 
> packets. This also helps in situations where ISIS core hiding is being 
> used, since if a traceroute is sourced from the wrong IP, the boxes on 
> the path may not know the route back to it and the trace fails in 
> similar fashion.
>
> Your illustration of problems with traceroute would be one scenario 
> that might benefit from this variant, assuming that the specific 
> implementation in question can be configured to respond using a 
> specific address as the source IP, rather than simply responding on 
> whatever the ingress interface's IP address is.
>
> You may want to discuss this in section 11.
>
> Thanks,
>
> Wes George
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Anthony Kirkham
> *Sent:* Friday, September 09, 2011 12:28 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* [GROW] Final feedback please - kirkham-private-ip-sp-cores
>
> All,
>
> I have just posted a new draft. There has only been one minor 
> modification.
>
> Filename:       draft-kirkham-private-ip-sp-cores
> Revision:       06
> Title:          Issues with Private IP Addressing in the Internet
> Creation date:  2011-09-09
> WG ID:          Individual Submission
> Number of pages: 13
>
> I believe this is ready for publication. Any advice on the next step 
> would be appreciated.
>
> Regards
> Tony K
>
> -- 
>
> *Anthony Kirkham*
> *Solution Architect**
>
> *World Wide Security*
> *Service Practice*
> *
> [email-masked] <mailto:[email-masked]>
> Phone: *+61 (0)7 3238 8203*
> Mobile: *+61 (0)401 890 494*
>
> CISSP, CCIE# - 1378
>
> 	
>
> Level 12, 300 Adelaide Street
> Brisbane, Qld, 4000
> Australia
> Cisco home page <http://www.cisco.com/global/AU/>
>
> 	
>
>
>
>
> ------------------------------------------------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject 
> to copyright belonging to Time Warner Cable. This E-mail is intended 
> solely for the use of the individual or entity to which it is 
> addressed. If you are not the intended recipient of this E-mail, you 
> are hereby notified that any dissemination, distribution, copying, or 
> action taken in relation to the contents of and attachments to this 
> E-mail is strictly prohibited and may be unlawful. If you have 
> received this E-mail in error, please notify the sender immediately 
> and permanently delete the original and any copy of this E-mail and 
> any printout.

-- 

*Anthony Kirkham*
*Solution Architect

***World Wide Security
Service Practice
**
[email-masked] <mailto:[email-masked]>
Phone: *+61 (0)7 3238 8203*
Mobile: *+61 (0)401 890 494*

CISSP, CCIE# - 1378

**

Level 12, 300 Adelaide Street
Brisbane, Qld, 4000
Australia
Cisco home page <http://www.cisco.com/global/AU/>

---

From: "George, Wes" <[email-masked]>
Date: Wed, 5 Oct 2011 08:54:15 -0400

From: Anthony Kirkham [mailto:[email-masked]]
Sent: Tuesday, October 04, 2011 8:24 PM
To: George, Wes; [email-masked]
Subject: Re: [GROW] Final feedback please - kirkham-private-ip-sp-cores

George,

I have not included discuss of implications for an IS-IS hidden core. I agree with your comments, however, I thought that discussion was moving a little away from the core topic.

well...
I was making the suggestion based on the following text from the draft:
A second approach to preventing external access to the core is IS-IS
   core hiding.  This technique makes use of a fundamental property of
   the IS-IS protocol which allows link addresses to be removed from the
   routing table while still allowing loopback addresses to be resolved
   as next hops for BGP.  The technique prevents parties outside the AS
   from being able to route to infrastructure addresses, while still
   allowing traceroutes to operate successfully.  IS-IS core hiding does
   not have the same practical requirement for the core to be addressed
   from a small number of contiguous address blocks as with iACLs.

I realize that you're suggesting it as an alternative to using 1918 space as a means to protect the core links, but it has some of the same problems. If you don't plan to discuss at least the commonalities of the problems between the two options because it moves away from the core topic, then I would remove this paragraph altogether. Otherwise, I think you can get away with adding a line or two regarding the limitations of "...while still allowing traceroutes to operate successfully..." Possibly something as simple as "but care must be taken to ensure that traceroutes are using source and destination addresses that all of the routers on the path have in their routing table."

Thanks
Wes

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Anthony Kirkham <[email-masked]>
Date: Thu, 06 Oct 2011 05:55:44 +1000

Wes,

That is a good suggestion and I will add it.

Thanks
Tony K

On 5/10/11 10:54 PM, George, Wes wrote:
>
> *From:*Anthony Kirkham [mailto:[email-masked]]
> *Sent:* Tuesday, October 04, 2011 8:24 PM
> *To:* George, Wes; [email-masked]
> *Subject:* Re: [GROW] Final feedback please - kirkham-private-ip-sp-cores
>
> George,
>
> I have not included discuss of implications for an IS-IS hidden core. 
> I agree with your comments, however, I thought that discussion was 
> moving a little away from the core topic.
>
> well...
>
> I realize that you're suggesting it as an alternative to using 1918 
> space as a means to protect the core links, but it has some of the 
> same problems. If you don't plan to discuss at least the commonalities 
> of the problems between the two options because it moves away from the 
> core topic, then I would remove this paragraph altogether. Otherwise, 
> I think you can get away with adding a line or two regarding the 
> limitations of "...while still allowing traceroutes to operate 
> successfully..." Possibly something as simple as "but care must be 
> taken to ensure that traceroutes are using source and destination 
> addresses that all of the routers on the path have in their routing 
> table."
>
> Thanks
>
> Wes
>
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

-- 
----------------------------------
Anthony Kirkham

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 05 Oct 2011 21:56:45 +0100

> moving a little away from the core topic.

I agree. Section 11 is starting to grow beyond the original scope of the 
document.

Brgds,

[snip]

-- 
     Humans are allergic to change. They love to say, "We've always
done it this way." I try to fight that. That's why I have a clock
on my wall that runs counter-clockwise.   -- R.A. Grace Hopper

A. R. Ivanov
E-mail:  [email-masked]

---

From: "t.petch" <[email-masked]>
Date: Mon, 10 Oct 2011 15:30:32 +0200

---- Original Message -----
From: "Anthony Kirkham" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, September 09, 2011 6:27 AM
Subject: [GROW] Final feedback please - kirkham-private-ip-sp-cores

All,

I have just posted a new draft. There has only been one minor modification.

<tp>

Anthony

I notice that you include the grow chairs on your To: list but have not seen any
reply on-list from them.

The simplest way forward is for the chairs to propose, and for the WG to
support, the adoption of the I-D as a WG I-D, which can then be last-called and
submitted to the IESG for consideration.

A harder route is to persuade an AD to take on the task of guiding the I-D
through the IESG and into publication, harder because ADs are busy, overloaded
even, and are likely to prefer the former route as the load is then shared with
WG Chairs and WG.

I would like to see this published and wish it already were, given the current
discussions over the weil and bdqks drafts on OPSAWG.

At the same time, I think it should be polished a little more before submission.
I think that the coverage is fine, but find myself wishing the style was more
robust - I was taught that technical writing avoids adverbs, and here I find
them making the text more uncertain than I think it should be; also I find
myself querying some of the details.

For example, there are AS numbers which should be used as examples in
documentation such as this. I realise that many manufacturers' manuals do not do
this, but we should know better:-)

Likewise, the reference to RFC1918 addresses; is that the only type used, or do
some use eg 240/8 addresses (yes, I know about squatting)?

Leakage; part of the weil/bdqks discussion is around the fact that addresses
always leak, no matter how good your filtering on the periphery.  I would like
to see that called out (I know that RFC1918 addresses end up in the global
tables, I have not seen an analysis of how they got there, but this seems a good
candidate).

The references need some work; not sure what to do about the nanog reference -
probably take it out into a paragraph somewhere, [RFC3021] is in the text but
not at the end, and I would like a reference for PMTUD, if not for ICMP and
perhaps traceroute.

Tom Petch
</tp>

Regards
Tony K

--

*Anthony Kirkham*
*Solution Architect

***World Wide Security
Service Practice
**

CISSP, CCIE# - 1378

**

--------------------------------------------------------------------------------

All,

I have just posted a new draft. There has only been one minor modification.

Filename: draft-kirkham-private-ip-sp-cores
Revision: 06
Title: Issues with Private IP Addressing in the Internet
Creation date: 2011-09-09
WG ID: Individual Submission
Number of pages: 13I believe this is ready for publication. Any advice on the
next step would be appreciated.

Regards
Tony K

--

            Anthony Kirkham
            Solution Architect

            World Wide Security
            Service Practice

            [email-masked]
            Phone: +61 (0)7 3238 8203
            Mobile: +61 (0)401 890 494

            CISSP, CCIE# - 1378

            Cisco home page

--------------------------------------------------------------------------------