#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# Network Mobility WG (nemo) Minutes
# IETF 62 Minneapolis
# Wednesday, March 9 at 1530-1730 @ SALON D
# Session chair:
# Thierry Ernst, WIDE at Keio Universiry <ernst@sfc.wide.ad.jp>
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Minutes:
- The following persons should be blamed:
Primary: Greg Daley Monash University <greg.daley@eng.monash.edu.au>
Secondary: Masafumi Watari, Keio University <watari@sfc.wide.ad.jp>
Jabber: TJ Kniveton (TJ), Alexandru Petrescu (AP)
Final compilation: Thierry Ernst
- Initials for people involved in the reported discussion:
Greg Daley (GD).
Thierry Ernst (TE).
Vijay Devarapalli (VD)
ChanWah Ng (CWN)
Marcelo Bagnuto (MB)
Ryuji Wakikawa (RW)
Basavaraj.Patil (BP)
Vidya Narayanan (VN)
Kent Leung (KT)
David Hankins (DH)
Will Ivancic (WI)
Andrew Dull (Connexion) (AD)
Erik Nordmark (EN)
James Kempf (JAK)
Suresh Krishnan (SK)
o Meeting Information
- Attendees:
Room150+
Mcast: no money, no mcast this time
Jabber: 4+
- Jabber logs:
http://www.xmpp.org/ietf-logs/nemo@ietf.xmpp.org/2005-03-09.html
- Audio:
mp3 at Salon D http://www.ietf.org/audio//ietf622.m3u
- Slides:
Meeting material: http://www.mobilenetworks.org/nemo/ietf62/
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 1. Agenda, welcoming, etc .......................................05mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Introduction by Thierry Ernst
- WG document status.
- Reports from TAHI and Connectathon
- v4 traversal: Vijay Devarapalli (VD)
- Multihoming: ChanWah Ng (CWN)
- NEMO and Multi6: Marcelo Bagnuto (MB)
- Status of NEMO Route Optimization: (CWN)
- NEMO Additional WebPage http://www.mobilenetworks.org/nemo
- Check slides later.
- Links to issues pages for various documents from this page.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 2.a NEMO WG Status................................................15mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o WG status reported by Thierry Ernst (see slides)
o NEMO Basic Support Protocol Specification
- http://www.ietf.org/rfc/rfc3963.txt
- RFC3963 Standards Track. Jan 2005.
- Implementations: available on Linux 2.6 and BSD
(e.g. see http://www.nautilus6.org/implementation)
- TE going on additional webpage now.
- Information about all implementations will be put on mobilenetworks.org.
Name of Implementation:
URL:
More information
Would be very useful.
o NEMO Basic Support MIB
- http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt
- No updates. Authors should still working
o NEMO Terminology / NEMO Goals and Requirements
- http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-03.txt
- http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-04.txt
- Issue page: http://www.sfc.wide.ad.jp/~ernst/nemo
- Check web for issues
- Would like to ship to IESG ASAP. Already said so many times.
- Couple of issues need to be resolved.
- Would like comments from WG on issues marked "VALIDATE" before closing.
- From issue page:
click on any issue, have title,discussion, new text.
- If you don't disagree with change, will have these issues as closed.
- If no feedback, will close and send to IESG.
- Nemo Requirements Issues: Some listed on the same page.
o Prefix Delegation
- Mobile Network Prefix Delegation [Candidate as WG doc]
http://www.ietf.org/internet-drafts/draft-kniveton-nemo-prefix-delegation-00.txt
- DHCPv6 Prefix Delegation for NEMO [EXPIRED - Candidate as WG doc]
http://www.mobilenetworks.org/nemo/drafts/draft-droms-nemo-dhcpv6-pd-01.txt
- Distributed Prefix-Delegation Scheme for NEMO [Recent Submission]
http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-autoconf-00.txt
- Mobile Network Prefix Delegation extension for Mobile IPv6 [EXPIRED]
http://www.mobilenetworks.org/nemo/drafts/draft-paakkonen-nemo-prefix-delegation-00.txt
- WG milestone, a prefix delegation document.
- History:
2 years ago (last revision, expired)
newer document based on DHCPv6 (now expired)
- Alper said optimization remove part and resubmit.
- Didn't get enough comments on TJ's draft (see mail).
Concern since last IETF draft was not on the IETF repository
- On the ML, was asked for acceptance, but not sure about whether it
was appropriate.
- Now is the right time to say something.
(silence).
- So, draft-droms and draft-tj should be accepted as WG doc.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 2.b NEMO Home Network Models..................................... 05mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Related doc:
- http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-02.txt
- Issue List:
http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issues.html
o Presentation by Vijay Devarapalli (see slides)
- Quick update. not many changes. v2 submitted recently to address
- URL in slides.
- Few editorial changes.
- Major issues 2 & 4
- Currently in all models.
- MR configures an address from MNP, or Home link.
- Isse Suggested that Home link, with MNP being separated (??? GD)
- Resubmit and IESG.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 3.Report of TAHI and Connectathon events......................... 10mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Presentation by Ryuji Wakikawa (see slides)
- Results of the connectathon 2/28-3/4 in San Jose about NEMO implementation
interoperability.
- 3 Implementation: HUT, WIDE, Nokia
WIDE KAME (BSD)
WIDE Nautilus6/HUT (Linux)
Nokia Research on IPSO stack.
- Conformance tools:
MR test suit from TAHI Project
TAHI test only supports MR, none for HA currently
34 conformance test items
- Interoperability Tests and performance
Binding Registration
Tested 3 scenarios, both explicit and implicit mode
Home Reg, Home Re-reg/Dereg
Nested Case: MR behind MR works fine
DHAAD
Multiple HAs on the home link: mix of NEMO HA and MIP6 HA
reply only contains NEMO HAs.
Tested Binding Ack status values 141,142,143
Which are defined for NEMO basic support.
- Interoperability fine, no bugs in spec found.
o Discussion:
- GD: is Usagi/HUT different ?
- TE: USAGI is working on the kernel side, HUT on userland (MIPL2.0)
The Linux NEMO implementation (NEPL) is a cooperation between HUT
and Nautilu6, another WIDE team; it made test / debug of NEPL.
Implementation is done by HUT.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 4. V4 Traversal for NEMO Basic Support........................... 20mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Related document:
IPv4 Care-of Address Registration
http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-v4tunnel-01.txt
o Presented by Vijay Devarapalli (see slides)
- IPv4 traversal for IPv6 mobility protocols.
- IPv4/IPv6 MR may be supported in a v4 network.
HA to handle v4 care-of-address. v4/v6 tunnel between HA and MN's
v4 visited address
o Issues regarding v4 traversal on NEMO basic:
- MR might end up on an IPv4 only access network
- MR treats v4 address os CoA and registers to HA
- doesn't require a tunnel
o Issues with using transition tunnels and mobility tunnels
- Double tunneling with IPv6 over IPv4
- Movement Transparency on IPv4 acess network
- tranition tunnel breaks when MR moves
- Mobility for transition tunnel and NEMO tunnel is needed
- Security between MR and HA
v4/v6 header and v6/v6 for NEMO. lots of overhead, really large.
Movement to the v4 network, MR needs to wait until transition
tunnels are set up, before signaling.
Security considerations: no relationship between MR and Transition
routers, preferred that MR negotiates with HA.
o Observation:
- MR is dual-stack, support IPv4 and IPv6
- HA support IPv4 and IPv6
- Collapse HA and transition router into the same box
Discovery of v4 addresses.
Static config?
DHAAD when in IPv6 network?
o Requirements:
- Establish single tunnel between MR and HA
NEMO is a tunnel protocol,
- Support NAT Traversal
- Support mobility for transition tunnels
o Solution:
- Send BU to Home agent's V4 address.
- BU for registration
- First Deregistration for v6 and then registration of v4/v6 tunnel.
o Modification to binding update:
- Mobile IPv6 CoA deregistration.
- Mobile IPv4 CoA registration.
- Also used IPsec to do BU, BA, MPS, MPA
- SA between IPv4/IPv4 care-of-addresses.
- NAT traversal: NAT detection using IKEv2.
- If there's a NAT, use UDP IPv6 in UDP over tunneling.
- Extension very small.
- Implementing on Shisa (KAME)
- Movement detection almost done
o Presentation over: Discussion
- GD: About "movement detection on both networks"
Would you like to give input for DNA ? ;-) laughs
- RW: Movement detection on v4/v6 very tricky
DHCP takes a long time, to get an address.
Still possible to roam to v4/v6 network.
Possible issues, how to work with DHCP in IPv4 network.
- ??: how does it wortk if you wish to put v4 to the edge and use
transition tunnel.
- RW: Fundamental assumption HA support both v4 and v6
- Not always a deployment scenario.
- v6 HA well inside v4.
- Even in this scenario works fine, need changes
- RW: there are many scenarios of course, but we need a simple
solution quickly. Many people starting service with NEMO,
need a transition mechanism.
There is no v6 network everywhere, can't wait for infrastructure.
If NEMO can deal with this issue, then it's much easier
Running v4 network all way inside v6.
- VD: Don't run native v4 inside v6 network, set up tunnel with box on edge
- VD: v6 network inside tunnel.
- SK: Are you pushing home network all way to the edge?
- VD: you don't have to put it on the edge. This is 1 possibility
- VD: No that's only one network [??]
- ??: Working on a transition with the v4 on the mobile.
- VD: If the HA doesn't support v4, transition tunnel to v4 on the fixed HA.
- RW: Most of the HAs support v4, but may not have an address.
- VN: Collapsing the access to the HA, R U introducing security issues ?
- RW: require SA between HoA and CoA
- VN: You may have to do something in the firewall to allow access to
the HA
- RW: v6 ha is reachable
- BP: exposing to what ?
- VN: HA has a globally reachable IP address
- BP: You are not hiding the HA from anything.
Typically the HA is not something you'd put in the DMZ.
- Something you'd put in the DNS, not really hiding.
Doesn't really matter, not hiding anything.
- ??: Fundamental changes not so tightly integrated.
- RW: only one sub-option, not a big modification,
- BP: very closely integrated with MIPv6, not really the case.
I don't think it's necessary
- RW: take a long time. Much harder than v4 transitioning method
- BP: don't mention Transition tunnel on the HA, you'll get in a rathole.
- KL: Most of the debate here is: is this the most typical or most
common scenario. This is a solution, how you deploy it is a
different issue. We can't figure this out the ideal solution
right now. Based on v4, placement of HA becomes an issue.
Debate or find out, gathering a problem statement to find out
whether this is a scenario we can solve. If this is the problem,
this is a good scenario.
- SK: Instead of two tunnels, one extra header. Applicability means
that all the tunnel issues become less relevant.
- Alpesh: any plan solving
- PS may just expand scope.
- VD: may need to come up all the scenarios.
- BP: boil the ocean or work on something solvable? Solve one scenario
that is most applicable
- RW: Problem must be quickly solved.
- KL: Some good thoughts, using something to cover both scenarios,
enterprise router covers some.
There is a superset of solutions, which is very pointed.
If Doors cannot solve this scenario, then this [??]
There's an alternative way of covering this solution, but there's
only need for a simple solution.
Need quick standardization, otherwise deployment is limited.
- RW: Doors is an alternative way
- DH:Difficulties with DHCP, was it the lease time?
- RW: It's the detection time whether v4 or v6 address
- DH: What is the reasonable time,
- Depends on whether DHCP is triggered, trigger DHCP whenever
the link changes.
Basically MR doesn't care about v4 stuff, it's only v6, so we have
to modify. Need quick hack.
- Brijesh Kumar (BK): We don't want to build another transition mechanism
- GD: Doesn't matter, is transparent to hosts.
- VD: It's not a transition mechanism, it's for NEMO
- BK: Who wants to do this now?
- RW: Vehicle companies.
- VN: Answer is not zero. Today it may be, but required almost
immediately. Not far in the future.
- SK: Think it's a good idea, and have seen another idea similar.
Have seen Flarion's idea, has pretty much same idea.
- RW: Haven't seen can you show me?
o Sense of the room:
- How many people think this topic is interesting? 30-50
- How many people think it is appropriate to work in NEMO WG ? 20-30
Draft presented would be "IPv4 CoA Registration" draft-ryuji-nemo-v4-tunnels
- How many read: 5-6,
Invite people to read the draft and comment.
o Discussion (cont):
- SK: Draft has applicability to more than NEMO.
- TE: Which working group?
- SK: MIP6 ask chairs?
- BP: applicability (MIP6 chair hat on) possible to do here of in MIP6.
Doesn't really matter.
- VN: What happened to miptrans?
- RW: on list, not any traffic.
- VN: last IETF draft-soliman-v4v6-mipv4-00.txt presented in 2 working
groups.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 5. Multihoming Issues............................................. 20mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Related document:
- Analysis of Multihoming in Network Mobility Support
http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt
- Issue List:
http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/
- Gola:
Update of the WG draft. The main focus of this slot is to get
consensus on the new text on identifying which issues to be solved
by the WG.
o Presented by ChanWah Ng (see slides)
- new version -02 submitted.
- Added recommendation on which WG should address the problems
identified in sec 4
- still too coarse, need to define specific issues for NEMO WG,
either in this meeting or the next.
- These are the current issues, in brackets need WG to look at problems.
- These are the MH issues we've noted in the draft. later I'll go into
- TE: Can you go back to the issues: important.
Some issues are very general (IPv6) and some are Multi6 or nemo.
Which are the important issues to solve in NEMO or to solve
in MIPv6, multi6.
- MB: about this list, do you want comment on specific points?
- MB: For Path survival, its probably more important to NEMO is should
be analyzed deeper.
There should be section for NEMO-link failure and more generic
failure link as discussed in multi6.
- MB: One point that is made very clear in the draft: one of the
important motivation for NEMO is ubiquity support, different
access media
This is a failure mode very specific for NEMO.
Need a MR/HA mechanism, rather than a generic survival mechanism
Much more frequent that other errors.
Access link survivability, to provide optimized support for
failures.
A lot of others are generic multi6.
- MB: Next issue Ingress filtering: I disagree with the conclusion you
reach in the draft
- MB: One important point: what are the motivations for having
multiple prefixes in the NEMO. IMHO, if not from artificial
creation, you don't have a NEMO specific issue here.
MR can handle. Not sure we have something specific for ingress
filtering.
- MB: Multiple Egresses to separate ISPs. That's my initial feedback
- CWN: on the last point, I'll give example with multiple prefixes
which aren't artificially created.
- TE: with multiple prefixes, you have a good reason to do it, is this
what you are saying ?
- MB: No, better see my presentation.
o Continue Presentation:
- CWN: Draft issues (not MH issues), 11 closed 11 open. 9 new issues
since Washington.
- Comment that multiple prefixes announced on a visited link.
Text resolution for issue 1.
- Issue 15: Source routing approach for overcoming ingress filtering.
Pointed out more complex issues.
Rewrite text to reflect issues.
- Issue 16: Exactly what Marcelo has been saying.
Discuss text which both agree on.
- Issue 17: reovery in routing infra.
Failure in network, can use network to recover.
Pointed out slow: 180ms, end-to-end may be faster.
Resolution unclear.
- Draft issue 18 source address selection impacts fault tolerance
capabilities.
Rewrite
- Issue 19,
Suggested remove 4.11, prefix of a nemo may be injected in DFZ,
since no-one would do it that way.
- Issue 20,
Normative and informative references, but this is informational.
- Issue 21, Applicability of appendix B,
Added section where it clarifies this.
- Issue 22:
Applicability of multi6 to NEMO,
Raised concerns, but need more analysis before multi6 is applicable.
MB giving a presentation, based on feedback, can be used to resolve
the issue.
o Moving forward:
- when we know the useful configuratiomn then we can figure out what's
for NEMO to do (what issues should we work on)
- TE: any questions or comments?
- TE: Some interest from specific industries, some have different
configurations in mind. Good if you could show if you're
interested in one particular scenario. Aircraft for example
- AD: Admit not up to date with draft.
Some of the issues in multi6, not convinced we've determined we
know how to solve yet generally.
Good to have these ideas, need to figure out how core
will do it without worrying about the edge.
- CWN: Depends on what industry wants? Do they want to wait?
Do they want NEMO to solve the problem ?
- AD: How we deploy 6 is orthogonal to how 6 is deployed in the core.
May be earlier or later than the core.
Drivers are address space and what methods of mobility meet our needs.
- WI: multihomed MR, advertisements occuring at the HA, they are sort
of different problems. Keep that separate.
- AD: Problem which comes up is the distances between HAs,
how you do tunneling optimization. Transatlantic at high
bandwidth is poor. Tunneling twice is going to change the
way the solution looks like.
- A lot of the people are looking from a smaller area point of
view. Smaller regional or geographic area, inside US or Japan.
The way mobile network work today is that people are moving in
a small network. So backhaul of network is different that when
you have a backhaul across an ocean or multiple oceans.
So tunneling gets worse and worse.
- WI: Agreed, multiple HAs geodistributed is useful, also need to
understand peoples needs
- KL: not sure for Mobile networks support, some are interested in
solutions which aren't regional, but each solution has limitations.
- TE: To everyone, please speak about your scenario, and what you need
for your usage. This will help to decide which configurations and
thus which issues must be solved in priority.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 6. Multihoming: NEMO and Multi6.................................. 10mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Related doc:
- Application of a multi6 protocol to nemo
http://www.ietf.org/internet-drafts/draft-bagnulo-nemo-multi6-00.txt
o Presentation by Marcelo Bagnulo (see slides)
- MB: Relate presentation to AD comment.
- Goal: to understand in which cases multi6 will NOT solve the problems.
- After this we can decide what we want to solve or if we want to wait for multi6.
- Understand what could be the possible application for multi6.
- Only NEMO basic, not RO.
o Multi6 basic assumption:
- multi6 or shim6 solution is far from being defined,
but consensus on characteristics
- multihoming -> multiaddressing
- different ISPs -> different prefixes
- prefixes of the packet determine path
- change prefix -> change ISP (rehoming)
o First case: 1 MNP (*,*,1)
- Only one prefix announced in the NEMO,
- multi6 can't help
- Artificially create prefixes to make multi6 work ?
- One prefix for mobile router.
- Is this a regional approach? Links between one or more MR and one
or more HAs.
- Need all endpoints in internet to be upgraded to support this local
problem
- Can modify HA and MRs transparent to packet transfer....
o 2nd case: 1 HA and multiple prefixes (*,1,n)
- home network is multihomed.
- home network has multiple ISPs.
- in order to benefit from multihoming need multi6.
- selecting the prefix, this won't select the path between the MR and
HA.
- what can be done in this case: mutliple prefixes to multiple paths,
ends up in reduced fault tolerance.
- actually forbidding valid mechanisms in order to tie to a specific
case.
- create artificial prefixes, if have N prefixes, need many prefixes
to associate between different paths between MR and HA.
- this is a big solution for a local problem. Is it overkill?
3rd case: Multiple Prefixes and Multiple HAs (*,n,n)
Case a) all HAs are served by same ISPs
similar to (*,1,n)
all HAs handle any of the prefixes, this is a distributed HA
equivalent, no interdomain problems. Probably HA-HA protocol,
with recovery procedures.
Case b) each home network dserved by ifferent ISP,
HA acts as a border router.
Selecting the prefix selects an ISP, fits within multi6.
Case c) Hybrid Case.
Some served by same ISP, some served by different ISP,
Use both methods. HA-HA.
o Summary:
- Only case that could be an application of multi6 is (*,n,n)
(multiple HA, and multiple Prefixes) each served by distinct ISPs.
- Other cases: introduce artificial MNPs.
o Other comment:
- by Erik Nordmark: pointed out that application of multi6 between MR
and HA, but we're not sure about the complexity of such a solution.
o Conclude presentation:
- TE: Thanks for maintaining the connection between multi6 and nemo
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 7. Current Status of the NEMO RO Discussion on the ML........... 20mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Related I-Ds:
- Taxonomy of Route Optimization models in the Nemo Context
http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-04.txt
- NEMO Route Optimization Problem Statement and Analysis
http://www.ietf.org/internet-drafts/draft-zhao-nemo-ro-ps-01.txt
- Route Optimization with Nested Correspondent Nodes
http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-01.txt
- NEMO Route Optimisation Problem Statement
http://www.ietf.org/internet-drafts/draft-clausen-nemo-ro-problem-statement-00.txt
o Presentation by ChanWah (see slides)
o Current status:
- current analysis pretty much comply with the charter:
- dtailed problem statement for RO is done
- analysis of various approaches
- analysis of issues and tradeoffs involved
- interaction between RO and IP routing
- security considerations for the various approaches:
- some may need more work?
o Topic discussed on the ML:
- should we separate PS from solutions analysis
- draft should avoid being solution-specific
- how complete is the document to be on analyis
- how to classify the entire solution space.
- Intra-nemo problem: When there's nested NEMO, tree discovery to
avoid loops may be needed. MANET proposal can be used.
- Tradeoffs between BU storm/signaling storm. What the effect of RO
is, compared to delay.
- Discussion on AAA, within the NEMO network.
- RR test for network prefixes (see next presentation)
o Contents of WG draft.
- Between Authors, reached agreement of what we want in WG draft.
- PS
- Analysis of RO approaches
- Related issues/tradeoffs of RO
- Appendix? Classification / Evaluation criteria
o Discussion:
- JAK: PS and Analysis should be separated.
- JAK: Does analysis contain security considerations?
- CWN: Yes
- TE: Possibly split things ?
- CWN: Finalize contents of drafts and determine if 1 draft or 2.
- TE: In which draft do you intend to base the problem statement or taxonomy?
- CWN: some members want a very short problem statement, one on RO
analysis for solution space.
- TE: What is the consensus of authors (all drafts)?
- CWN: use draft thubert-ro-taxonomy as the base (most mature and complete doc)
- GD: we should separate problem statement and the analysis
- JAK: Need threat models not tied to solutions.
- TE: need to think about potential solutions to clarify the problem
- JAK: of course but then need to abstract out that into text.
- TE: Who has read draft-thubert:?
- TE: Who thinks should be approved as WG document.
- TE: currently draft-thubert has two sections. We could split it in two
- WI: Is the question that we'll use it as a basis?
- TE: 2 parts taxonomy and PS, can be split in 2 and PS as WG document
and Taxonomy as individual for now.
- VD: can't we do this in parallel?
- TE: 2WG documents?
- VD: yes
(silence)
- CWN: What has been said today is that the first part of
draft-thubert will be used as basis of problem statement?
- TE: use draft-thubert, split in two, 1 for PS, 1 for taxonomy.
- TE: let's take this to the ML to make sure of the consensus
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
# 8. Security issue of sending prefix-scoped BU to CN ............05mins
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
o Related doc:
- Extending Return Routability Procedure for Network Prefix (RRNP)
http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt
- Purpose of this slot: Raise WG awareness on the inadequacy of RR
with prefix-scoped BU
- WG Relevance:
It is a consideration for the WG when analyzing NEMO-Extended.
o Presentation by ChanWah (see slides)
- This presentation was for washington, but didn't have time.
- In order to achieve NEMO RO, the MR or MN could send BU to CN with
mobile network prefix option
- 1. MR-CN Opt: CN can have MNP in Routing table, routes to the MNP
through the MR's COA/.
- 2. Infrastructure Opt: MR can send BU with MNP to CR; CR informs MR
which prefix it manages
o Security threat 1
- when BU with MNP option changed en-route by attacker
- or when normal BU inserted with bogus MNP option.
- Attacker can use this to launch an attack on the MR
(CN or CR direct to MR packets not intented to MR)
- threat can be protected by RR
o Security threat 2:
- If MR is malicious, claiming to manage MNPs it doesn't own
- RR only verifies that the CoA and the HoA colocated, not that the
CoA, HoA and MNP colocated.
- threat not protected by RR
o Extension to the RR procedure.
- Keygen token by CN, NPK, to random address configured from MNP
- MR intercepts and use to generate binding management key
o Discussion:
- GD: need strong trust since you can't authorize route even if you have
HoA, CoA and MNP
You need routing certificates.
If you don't have that you shouldn't allow it to inject routes
- Pekka Savola: I agree with GD but in case you really need a
solution, this doesn't required all of that.
- There may be a RR test that kind of guarantees that the router (or
the one that claims to be a router)
- GD: Unsufficient, because you are changing routing
- GD: on-path attack is a valid attack and the damage is more severe
- GD: RR is one thing but might need something very clever indeed
- Be clear on what threat analysis is: are we concerned of on-path attackers ?
- JAK: SEND routing certificates can be used.
- SK: Node on the mobile network send out without Router knowing,
If there's no SEND, the router could spoofed.
- MB: Not sure if this is worth it.
What are we gaining , need to change all correspondents, right ?
For CNs talking RO to all Hosts in nemo to reduce all signaling to one.
- CWN: We are not debating the RO solution, the draft is raising awareness
If you put prefix in BU, then you have this threat
- SK: Could be a CR on the other side
- MB: Injecting routing information into routing system, now worried.
- SK: Applicability statement would apply.
- VD: Other sol: anycast address, like DHAAD from prefix set aside.
Agree if prefix length is fixed.
- CWN: if variable prefix length need as many anycast addresses...
- TE: Meeeting concluded.
|
