Subject: Re: [rrg] RRG recommendation

From: "Stephen D. Strowes" <[email-masked]>
Date: Sun, 01 Nov 2009 20:06:14 +0000

Hi,

Scott Brim wrote:
> - NAT is now architecture.  The IETF needs to decide how much NAT it
>   wants the Internet to have in the future.  This strongly influences
>   what we do in routing/addressing, because outlying, dwindling cases
>   (either the NAT ones or the non-NAT ones) can be handled specially.

I suspect the IETF collectively knows that it would prefer exactly zero 
NAT deployment, but that it is currently stuck with it in an IPv4 
universe. I further suspect that the IETF's preference for a future 
Internet would not include NAT, primarily for the technical reasons that 
  a larger layer-3 address space renders NAT redundant, and that even 
the best-behaved NATs can cause problems for many transport protocols.

However, it seems that NAT is a technology people are unfortunately used 
to, that many people like, and that possibly some are uncomfortable 
without. Some recent efforts in the IETF (e.g., NAT66, HomeGate) at 
least acknowledge NAT is probably here to stay, while suggesting that 
standardised behaviour may ease future protocol development. In a sense, 
the "least evil" future of NAT. There's also the work on NAT traversal 
over existing non-standardised NAT44's, such as ICE.

I'm not convinced we arrive at an answer by throwing the question of 
dealing with NAT over the fence to the IETF. Might it be enough to 
assume for a future Internet that either: NAT deployment tends toward 0% 
as IPv6 deployment rises, or that future NATs adhere to certain 
well-defined behaviours for which we have a reasonable set of NAT 
traversal techniques to work around?

(Note in all of the above that I'm not involved in the IETF beyond 
passively watching a handful of mailing lists and remotely listening to 
some WG meetings.)

-S.

---

From: Christian Vogt <[email-masked]>
Date: Sun, 1 Nov 2009 21:39:55 -0500

On Oct 27, 2009, William Herrin wrote:

> http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGTerminology
>
> I thought they were crap and I wasn't alone. [...]

Then perhaps we should revise the definitions.  We are talking about
terminology that will be fundamental for writing the RRG recommendation,
so a wide acceptance of its definition is clearly desirable.

Personally, I believe that the present definition could be simplified.
After all, the only thing that matters is the distinction between names
with and without topological significance.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Sun, 1 Nov 2009 21:46:32 -0500

On Oct 26, 2009, Scott Brim wrote:

> - Loc/ID separation is not directly routing's problem.  [...]

Scott -

FWIW:  I believe what you mean here is that an ID/locator separation
would not necessarily require changes to the routing system, right?  I
would agree to this.  However, what your statement looks like is that
ID/locator separation, or rather the lack thereof, does not contribute
to the routing scalability problem.  And this is at odds with the fact
that both the multi-homing problem and the renumbering problem are
consequences of a lack of ID/locator separation.  It is also at odds
with the observation that most proposed routing scalability solutions
introduce ID/locator separation in some way.

- Christian

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 9 Nov 2009 23:04:23 -0800

best effort in responding email before Friday

On Oct 26, 2009, at 7:36 AM, Scott Brim wrote:

> Lixia Zhang allegedly wrote on 10/24/2009 1:20 AM:
>> Talking about Hiroshima: according to the RRG plan, the Hiroshima RRG
>> meeting will be focusing on the discussions of RRG recommendation to
>> IETF on scalable routing solutions. There is precisely two weeks  
>> before
>> Hiroshima now, lets get the discussion started on the list first.   
>> I'm
>> going through all the exchanges since Stockholm by subject groups,  
>> in an
>> attempt to make a summary.
>>
>> Lixia
>
> Ah good.  Here are some suggestions on what to tell the IETF:
>
> - How to think about routing architecture at all.

Good point.
Here is a paper explaining our answer to that question:
   "An Evolutionary Path Towards Global Routing Scalability"
   http://www.cs.ucla.edu/~lixia/aggregation.pdf

>  We have a start on
>  this in the draft recommendation, but it should be organized a little
>  better I think.  We've tried before, but I think the time is better
>  now.  I don't know how you want to discuss that.
>
> - Loc/ID separation is not directly routing's problem.

a concise and precise statement!
I can't agree more.
(this assumes that the "ID" here means real identifiers, not the ID in  
the name of LISP)

>  The root cause,
>  and the pivot point for a solution, is identification functions that
>  use topology-dependent information as input.  These functions are
>  primarily in endpoints but are also in network infrastructure.  They
>  should be fixed, to the extent they reasonably can.  Where they  
> can't,
>  then routing, mobility, etc. must take up the slack.  The RRG
>  recommends to the IETF that it needs to decide where that line is --
>  what identification functions will they assume will be fixed and  
> which
>  not -- so that other Internet technologies, particularly routing, can
>  have a clearer idea what they have to do.

hmm, not exactly clear about all the above, in particular I am not  
sure what it means by "where that line is"... line between what and  
what?
Routing is about addresses.

ISOC held a reception last night to thank ISI's over 30 years of  
service as RFC editors, Bob Braden made a remark about Postel's  
architecture vision that moved me, and also reminded me about a talk I  
gave a year back at NANOG that recounted Postel's comment on how to  
address routing scalability problem.
the presentation slides are at:
http://www.nanog.org/meetings/nanog44/presentations/Wednesday/Zhang_Wed_N44.pdf

In particular I would like to draw your attention to pages 6 - 8.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 9 Nov 2009 23:29:27 -0800

On Oct 27, 2009, at 11:37 AM, Eliot Lear wrote:

> On 10/27/09 5:27 PM, Scott Brim wrote:
>> If I understand correctly, I believe it is fundamentally important.
>> However, it can be handled through various dynamic lookup services  
>> (e.g.
>> DNS), no?
>>
>
> Maybe.  It depends on the dynamic lookup service.  Most of them  
> break in the face of multiple layers of NAT.

very true.
and I would like to remind everyone that what we are talking about is  
this global routing infrastructure, that most or all the other  
critical infrastructures of our society depend on.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 9 Nov 2009 23:43:30 -0800

On Oct 27, 2009, at 12:36 PM, William Herrin wrote:

> On Tue, Oct 27, 2009 at 2:45 PM, Scott Brim <[email-masked]>  
> wrote:
>> I thought the concepts came out very clear in the end.  See our
>> definitions on the wiki.  How to implement identification functions,
>> e.g. with stack names or what, wasn't resolved, but we know what the
>> classes of functions are so RRG can model it.
>
> Hi Scott,
>
> I thought they were crap and I wasn't alone. Heck, the locator
> definition is so vague it barely means anything at all. More to the
> point, it means virtually anything the reader wants it to mean,
> regardless of what the writer intended. Do you really want to risk
> using those terms when more precise words can convey your meaning?

Hi Bill,

personally I share your view that the current text on that page is  
inadequate.
I'd also like to suggest that we take constructive actions to help  
improve it.

I recall we made a good start on the terminology definition at SF IETF  
early this year, the slides is at
   http://www.ietf.org/proceedings/74/slides/RRG-6.pdf

in particular slide 5 was resulted from the group discussion, which is  
copied below:

    How many different things
    That are needed in the context of routing scalability?
1. IP prefixes that are in the DFZ routing table
2. IP prefixes that are not in the DFZ
   – Example: this thing that LISP called “EID”, but really
     not an end point identifier
3. “endpoint” identifier
   – Outside the routing system (local or global)
   – Debates going on whether calling it “Stack ID”
4. At least one additional identifier needs to be defined
   – Either identical to #3, or closer to application than #3

At the time the plan was to turn this into an internet draft. Maybe we  
could pick up from here?

Lixia

---

From: William Herrin <[email-masked]>
Date: Wed, 11 Nov 2009 19:04:54 -0500

On Tue, Nov 10, 2009 at 2:43 AM, Lixia Zhang <[email-masked]> wrote:
> I'd also like to suggest that we take constructive actions to help improve
> it.

Hi Lixia,

Let's start with the definition of "address." Do we know enough at
this point to start redefining the concept of a network address in
terms of other elements? I'm comfortable saying that we know enough
about the overloaded functions on an address to be pretty sure we
don't yet know enough to concisely redefine "address" in terms of
those functions. We might want to define other elements in terms of
the network address but I'd like to see us leave the redefinition of
"address" for later researchers who've seen the components in use
individually.

Next, let's realize that there are THREE categories of information
relevant to the RRG that the address interacts with, so as we define
elements like locator or identifier, we should expect to find at least
three. Not merely two. The categories are:

1. information used directly by the packet forwarding process to move
data packets to an endpoint.
2. information used to anchor the relationship between a
communications endpoint and a specific set of packet forwarding
processes which reach it.
3. information which is entirely unrelated to the packet forwarding process

A key observation here is that everything within the scope of our
discussion ties back to the packet forwarding process. Not the more
abstract notion of network topology and certainly not the vague idea
of a network attachment. Any elements we identify in these three
categories, then, should be definable in terms of a precise
relationship to the packet forwarding process.

Examples of network address use in each of the three categories include:

1. The IP destination address looked up the FIB for packet forwarding.
2. The IP source address which specifies an endpoint to which return
packets should go. (The packet source address is NOT necessarily a
locator!) The DNS A record which maps an endpoint's hostname to a
current set of destination IP addresses.
3. The TCP connection ID composed from the source and destination IP
address and port numbers, used exclusively to associate individual IP
packets with the connection of which they're a part.

The difference in the three categories from a routing perspective is:

1. We'd prefer the packet forwarding elements change from moment to
moment with the network topology. If they don't, we have to force the
topology to fit the forwarding elements, making it very complex.
2. We expect the mapping to change when the forwarding elements change
so that whatever it maps from doesn't have to.
3. Elements outside the scope of the packet forwarding process should
never be required to change as a result of a change in the packet
elements used for forwarding process.

Important consequences of this are:

a. Locators aren't about network attachments. They're about the packet
forwarding process and more abstractly about the network topology. An
element that always has exactly one attachment to the network is
likely a holy grail. Case and point, the IP address on my BGP router
with two upstreams is certainly a locator but it clearly has two
points of attachment.

b. Identifiers as we're currently discussing them blur the line
between information categories 2 and 3. When we correctly understand
them, if they're the right conceptual framework in the first place,
they'll fall squarely in one category or the other.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Nov 2009 05:20:09 -0600

Excerpts from William Herrin on Wed, Nov 11, 2009 07:04:54PM -0500:
> a. Locators aren't about network attachments. They're about the
> packet forwarding process and more abstractly about the network
> topology. An element that always has exactly one attachment to the
> network is likely a holy grail. Case and point, the IP address on my
> BGP router with two upstreams is certainly a locator but it clearly
> has two points of attachment.

I think this conflates two things we distinguished for a while, and
the distinction should not be lost.  I don't remember the name for the
second one, but we have

  - names for a network attachment points ("locator")

  - information used for forwarding at intermediate hops (forwarding
    directives?  something like that.  was it Noel's?)

Locators are not the only thing used by intermediate forwarding, and
in fact might not be used at all by some forwarder if other state info
suffices.

Scott

---

From: Tony Li <[email-masked]>
Date: Thu, 19 Nov 2009 00:36:10 -0800

>     directives?  something like that.  was it Noel's?)

Indeed, if you have explicit forwarding instructions, you use that.

Locators are necessarily about network attachments (per stack).  If a 
host has multiple points of attachment, then it should have multiple 
locators.  And only one identifier.

Regards,
Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 19 Nov 2009 11:23:51 +0200

On Thu, Nov 19, 2009 at 10:36 AM, Tony Li <[email-masked]> wrote:
> Locators are necessarily about network attachments (per stack).  If a host
> has multiple points of attachment, then it should have multiple locators.
>  And only one identifier.
>

Only one...?

IMHO, a PKI certificate identifies a stack/person/host so it is a
identifier in the RRG terminology, right?
http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGTerminology

A second identifier is needed, that will provide mobility (fixed and
mobile site, endpoint) and not as complex to deploy as a PKI
infrastructure, also less secure than the PKI infrastructure. Think
this needs be clarified, if not - there is a risk that the new
identifier will have too much security features and start to compete
with the PKI infrastructure??

-- patte

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 21:35:13 +0900

> with the PKI infrastructure??

When moving, your identifier will still be kept, not changed, but your
locator will be changed. The mapping between the identifier and the changing
locator (and its retrieval) will have to be done a server in the
infrastructure (perhaps an extended DNS or rendezvous server(?) in HIT) a
very efficient manner.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 19 Nov 2009 17:02:53 +0200

> infrastructure (perhaps an extended DNS or rendezvous server(?) in HIT) a

Yes, this is the host identifier approach - very similar as a PKI
infrastructure but the PKI doesn't offer mobility, the PKI certificate
do have global uniqueness . Another approach is to use a session
identifier that can offer mobility, the session identifier is not
globally unique - it is just used to identify the session when the
endpoint is moving from one attachment point to another.

Both identifiers can be used concurrently, if the context of the
session is sensitive then use the session identifier for mobility and
to identify the remote endpoint after the transition authenticate
again the endpoints by the PKI infrastructure.

If the content is not sensitive - do you need to authenticate the
remote endpoint again? Probably not, but mobility might be required
and for that the session identifier is good enough - usually it is the
client that moves around and the server is fixed. Or if both endpoints
moves around you would need a rendezvous server - but I think has been
solved on the application layer already, e.g. SIP registrar&proxy,
Skype, Instant Message solutions, peer-to-peer applications etc.

The problem is that some applications uses IP addresses to identify
the session, because there is no session layer in the TCP/IP-model
(the OSI model and Appletalk do have) - the lack of the session layer
is in my opinion the problem. So if the application could identify the
session with the help of a token much better mobility could be
achieved.
Unfortunately it would require changes to some applications - but it
is the right place to fix the problem. If the application can not be
changed and mobility is required, then use Mobile IP.
A simple session layer would make the networking so much easier.

-- patte

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 20 Nov 2009 00:23:55 +0900

> endpoint is moving from one attachment point to another.

Bought.

Yet, is PKI a necessity or a group consensus already? What about host
ID(HID) in HIP, which as I know is also protected. (Encrypted but not
authenticated?)

How is HID different from the PKI you described? Do they have the same
problem as PKI? I thought the main objective of HIP was to solve the fast
mobility problem, so their idea of HID(and so HIT) would not hinder fast
mobility, only if the rendezvous operation is efficient enough.

> again the endpoints by the PKI infrastructure.

Also bought.

> Skype, Instant Message solutions, peer-to-peer applications etc.

OK.

> session with the help of a token much better mobility could be

I'm a bit surprised that, in this Internet community, there're some people
ready to borrow an idea from OSI... :-). Or is it from Apple Talk?
I'm personally an admirer of Apple or more correctly Jobs.

> A simple session layer would make the networking so much easier.

Introducing the session ID would require a lot of change in the current
Internet operation. In the attempt of my proposal, I'd tried to minimize the
disturbance to the current Internet infrastructure. So, I chose to make
compromises even if it would not perfectly match a more ideal architecture
of my belief. If this discussion would be with the Future Internet
community, I'd have proposed a more drastically different idea.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 20 Nov 2009 10:16:23 +0200

> community, I'd have proposed a more drastically different idea.
Actually, the session ID is not that far away :-)
If you look into SCTP, there is a verification tag that have the
characteristics of a session identifier. Also Multipath TCP has
similar functionality, it is called a token. SCTP is available, MPTCP
is under construction.
And both transport protocols are supporting multi-homing, i.e. the
endpoint can have several subflows to the remote endpoint over
different interfaces. If you make some changes to the routing
architecture you could ensure that the subflows are routed over
different attachment points between the local network and Internet -
multi-homing service is no longer provided by the network, the
endpoints take cares of that themselves. And the routing architecture
becomes simpler, also endpoint mobility is an extra bonus.

-- patte

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 20 Nov 2009 19:07:02 +0900

> becomes simpler, also endpoint mobility is an extra bonus.

Great.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Christian Vogt <[email-masked]>
Date: Mon, 30 Nov 2009 00:35:07 -0500

> with the PKI infrastructure??

Patrick -

One can certainly think of multiple types of endpoint identifiers.  But
shouldn't we focus on the identifiers that are required to establish
and maintain communication sessions?  A PKI certificate is not of this
nature, as it is used by applications given an existing session.

- Christian

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 30 Nov 2009 15:35:32 +0200

> nature, as it is used by applications given an existing session.

Hi Christian,

correct - that is what we should focus on, an identifier on how to
establish and maintain communication sessions. But it opens up a
possibility to hijack sessions, if the control packets during the
session transition are not protected - not all sessions need to be
protected that well, the SCTP verification tag or MPTCP token is
sufficient to provide mobility for basic browsing.

What if the existing session, that is protected by TLS or a PKI
solution, is moved from one endpoint locator to another endpoint
locator - is it still the same remote host after the transition?

Think multi-path enable transport protocols need to deal with this
issue - studies and proposals for SCTP has been done , e.g.
http://www.academypublisher.com/ojs/index.php/jcp/article/viewFile/02043140/302

But perhaps MPTCP can get around this problem in an easier way?

-- patte

---

From: Christian Vogt <[email-masked]>
Date: Mon, 30 Nov 2009 19:45:04 -0500

Patte -

I agree with you that, for security purposes, tokens of additional
namespaces will have to be used.  And I hadn't seen from your comment
that you referred to such stack-internal tokens.  

This said, I tend to mentally separate the identifiers that are used by
applications to initiate and maintain communication sessions, from other
tokens that may be used for security purposes at the transport and IP
layers.  The reason is that the former are first-class elements of an
Internet architecture, whereas the latter are engineering choices.  This
is a personal preference, however, and cannot be backed technically.

FWIW:  I agree with you regarding the strength of security needed to
protect IP address updates.  What we need is a solution that maintains
the level of security we have today.  Stronger protection of IP address
updates would be in vain given the vulnerabilities we have today.

- Christian