Subject: [RRG] thoughts on the design space 2: upper layer implications

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Jul 2008 15:21:32 +0300

This is a follow-up mail that attempts to list the different upper layer 
implications the various design tree branches have.

DATAPLANE
========

The non-aggregatable designs such as ROFL have several issues:
- From what I understand, it is hard to implement routing policies. We 
can't take away functionality that today's Internet system parts rely on.
- Addresses no longer provide any information about location, which is 
something that some applications use today. Not clear how significant 
this is, but I'm listing it here nevertheless.

The host-based identifier-locator split designs have the following issues:
- they break the 1 interface - 1 address assumption that many 
applications have (draft-thaler 3.2.3)
- they cannot help with PI needs or avoid renumbering
- multihoming is not possible with existing peers, because they do not 
support the extension. You can still communicate with existing peers, 
however.

Host-based IP layer designs have the following additional issues:
- Interference between what upper layers are doing with respect to 
failure situations, for instance application fallback
- Interactions between transport layer actions and failure detection 
schemes at IP layer

HIP, one of the host-based IP layer designs has the following further 
issues:
- Addresses no longer provide any information about location
- If there is no mapping system from HITs to addresses, referrals become 
a problem

Transport and higher layer solutions do not have additional issues.

The core-edge separation branch restores the notion that hosts have just 
one address (by employing one prefix visible to the hosts). However, it 
also introduces this issue:
- addresses provide locality information only within a domain

The encapsulation branch introduces these issues:
- reduced MTU, which can cause issues where PMTUD does not work (and it 
does not work well today)
- difficulties in talking to the existing internet

All translation designs have issues with referrals.

Two-sided translation has the same issues as encapsulation, with the 
possible exception of MTU differences.

One-sided translation has the issue that the addresses seen by one side 
are not the same as those seen by the peer; NAT-like effects can be seen.

One-or-two sided translation has no additional issues when used to 
communicate to an upgraded network. When used to communicate with a 
legacy network, it has the same issues as one-sided translation.

MAPPING RESOLUTION
===============

The caching design has a number of issues:
- If packets are dropped while cache entries are being fetched, there 
may be deterministic loss
- If packets are routed through a secondary path while cache entries are 
being fetched, there may be deterministic delay

Both of these are issues (draft-thaler 3.1.6-3.1.7). Exactly how serious 
issues is left for further study, however.

In addition, all designs with a mapping resolution system may have 
incentive and reliability issues due to the fact that a third party is 
needed. And, the non-caching design may have scalability issues.

Jari

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 25 Jul 2008 20:45:16 +0200

Jari,

> MAPPING RESOLUTION

Although this has not yet been largely discussed on the mailing list, I 
think that we should add that the security of the mapping resolution 
system is a concern. The mapping system should take security into 
account while few of the existing proposals have addressed this issue.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 26 Jul 2008 00:08:02 +0200

an open discussion during IETF71 rrg meeting resulted in an outline of
issues related to the mapping system. the outline (resulting from the
mtg debate) was distributed for comment on the list with the aim to
document these issues. unfortunately, and except if i missed it, no
follow-up came out of this exercise - any reason ? is there something
planned for this meeting ?

for inst. that outline listed the following issues on security:

Security considerations
-----------------------

- Interactions with drop/delay.  (Eliot Lear -- needs clarification
  please).
- Authorization: Don't take requestors down garden path.  Don't give
  them information they aren't authorized to actually use.
- Security of mapping system itself: updates authenticated .
- Authentication of map replies.
- Interactions between security of mapping system and security of core
  routing.

-> anything else to add ?

thanks,
-d. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Olivier Bonaventure
> Sent: Friday, July 25, 2008 8:45 PM
> To: Jari Arkko
> Cc: rrg
> Subject: Re: [RRG] thoughts on the design space 2: upper 
> layer implications
> 
> Jari,
> 
> > MAPPING RESOLUTION
> > ===============
> >

---

From: Jari Arkko <[email-masked]>
Date: Sat, 26 Jul 2008 16:36:39 +0100

Olivier,

> Although this has not yet been largely discussed on the mailing list, 
> I think that we should add that the security of the mapping resolution 

That's right.

Jari