[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] thoughts on the design space 2: upper layer implications
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: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 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
> > ===============
> >
> > 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.
>
> 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
>
> --
> to unsubscribe send a message to rrg-request@psg.com 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
>
Support for other network needs
-------------------------------
- Mobility.
- Impact on preferences for mobility approaches
- Does it meet mobility requirements
- Emergency services.
Differential Delay and/or Drop of initial packets
-------------------------------------------------
- Whether there will be any delay at all (might even get there
faster).
- Number of packets that might be delayed, dropped.
- Between sites and/or hosts.
- Trade off determinism of delay/drop versus agility & light weight.
Analyze based on how bad it would be.
- Effect on transport/session layers (e.g. congestion control).
- Effect on short elastic and long bulk flows.
- Ultimately only end user experience is visible.
- Possibility of difference classes of service?
Push, Pull, Hybrids
-------------------
- Possibly proactive, dynamic adjustment of behavior.
- By src/dst (site)
- Responsiveness
- Other parameters?
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.
Granularity
-----------
- What level of specificity?
- Ability to operate at multiple levels of granularity simultaneously.
Churn
-----
- How system responds with change in rate of intentional changes.
- Effect of changes to mappings on established flows.
Mapping points
--------------
- Flexibility in mapping points: end system, domain border, in
between.
- Placement of mapping points: those that own the mappings, those that
use them, or in a third party
- Who is authoritative for the mapping. Owner, holder, user.
Interaction between rate, state, and delay
--------------------------------------
- Interaction between rate, state, and delay.
Deployability (Incremental)
---------------------------
- Interworking with existing deployments.
- How soon are benefits seen?
- Who gains. Is it the one doing the deployment?
- Does a deployment require more than one party, coordinated?
- Easing v4=>v6 is not an issue.
Flexibility
-----------
- Possibility for hierarchy
- Ability to express preferences (policy)
Failure modes
-------------
- How does mapping system adapt to unintentional changes in reachability (if at
all).
- Dependence on something not on the data path (-> uncontrolled weaknesses).
- Resilience of mapping system.