Below are the minutes to the IETF 65 NETLMM meeting. I
combined minutes from
two takers and lightly edited them. Please review, and if
you find something
that needs changing, please let me know before next Monday
(April 3), at
which time I would like to send them to the Secretariat.
jak
-----------------------------------------------
I. James Kempf: Possible interoperability test
- goal to complete design by late summer
- first draft due in July
- go to IESG in August/September timeframe
- interoperability test in October
- vendors want to implement it
- implementations need to be ready in time
- volunteers needed to set up a venue, testbed, etc.
- volunteer needed for required/optional features
checklist
II. James: PS Draft
Issue #2 : Include Nonwireless Networks
There could be non-wireless access point or wireless
access point
Issue #5 : What does "network based" mean
Issue #6 Global Mobility Management Discussion assumes a
particular
architecture
III. James: REQ Draft
Issue #1 Remove or Move Gap Analysis
Move Section 3 to appendix , remove :"Gap
Analysis"
Keep "Gap Analysis"
Henrik: "it's good, but incomplete"
Gerardo: "I agree with James, to avoid lots of
comments and time
consumtion"
Keep in the appendix
Issue #11: document assumes an architecture
Add a solution in Section 1 that describes the NETLMM
Issue #12: Handover Performance Requirement is Vague
Add some words
Issue #13: Handover Signaling Volume Reduction Requirements
is vague
Resolution: clarify that the requirement to reduce
messages
Issue #14 Location Privacy requirement is a trivial
consequence of LMM
Resolution: changing this requirement to be not changing
the IP address
and use location privacy as one motivation
Issue #15 Requirements or design Goals
Kent: All requirements are design goals? There will be no
difference
between design goal and requirements.
Issue #16 Add backward compatibility/reuse requirement
Backward compatibilty is not a issue,
Gerado: evaluate this, Pro and Con
Henrik: Add in the resolution, much better statement than
backward
compatibility
Discuss on the list
Issue #20 Section 5 need better motivation
Resolution: Remove section 5 from document
James: Next Step
Plans for PS and REQ
- Update drafts with accepted issues after IETF
- Start 2 week WG last call on or about Apr. 1st.
- Line up some solicited reviews from people knowledgeable
in mobile
networking
- Conclude WG last call and WG discussion of solicited
reviews around end
of
April
- Submit to IESG around 1/5
IV. Christian Vogt: Threats draft on MN-AR interface
- New terminology needed (based on comments rec'd)
- MN authentication, MN identifier, Data origin
verification, data origin identifier, locator all
defined
- problem - spoofed data-origin ID and roaming at a
victim's cost. Data-origin verification could
prevent this, but only helpful in MN->CN direction.
May need firewall on the MAP to prevent this.
- problem - impersonation of MN during DNA. Impersonator
mimics the victim - requires attacker to use the same
IP address as victim. Limitation is that impersonator
cannot forward packets to the MN. Differnet from
MIPv6 scenarion, and not as severe.
- problem - impersonating during DNA. Limitation is that
attacker must redirect packets to itself.
- problem - rogue AR acts as man in the middle. May
eavesdrop the packets, modify them, forward on path
outside NETLMM. Limitation is that return packets
go thru NETLMM.
- problem - vulnerabilities of IPv6 ND/DNA
- problem - MN identifier associated w/ IP address.
Attacker can track victim's IP address. Could send
NS for victim and address resolution or DAD. Do ARs
forward ND signalling to other links for DAD?
- problem - location privacy. 2: Attacker btw AR and MAP.
Most effective if attacker is close to MAP. Can be
prevented by encryption. 3: Ip address tells victim is
inside NETLMM. Limitation - NETLMM prefix not precise.
- mailing list comments:
- implicit data origin identifiers may not show up in
packets (Julien)
- data origin ID can be MN-MAP security context
- draft does not mention flooding of MN's IP address
- more dangerous for existing IP address
- location privacy when attacker on access link
Microphone comments:
Greg Daley: if the person who signs the NS/RS uses the
same SEND private key there is no problem. Is this too
high a bar for NETLMM?
Kent Leung: MN<->AR interface and AR<->MAP
need
to be considered. Need to address AR<->MAP
security.
Can take care of this in protocol design draft.
Hesahm Soliman: are you assuming threats on data
traffic, and why is this particular to NETLMM? If
signaling is done properly there is no threat.
Hesham: do you assume ingress filtering/SEND? There
are a number of assumptions made. Will clarify with
design team.
Suresh Krishnan: how will ingress filtering work?
Needs to be documented.
Vidya Narayanan: ingress filtering is not particular to
mobility.
Authentication issue - somehow the MN knows the AR is
authenticated. Need a BCP on what should be done.
Vidya: MAP-to-AR interface is well understood; can
you just run IPSec?
James: Title is misleading - will change to
reflect the context.
Pete McCann: quite likely there will be EAP and 4-way
handshake at link layer.
Kent Leung: need to focus on MN<->AR interface.
NETLMM is different from IP routing; need focus to
understand new threats.
Alex Petrescu: Is the design team working on the
MN<->AR
interface? No - only on AR<->MAP interface
Vidya: needs to be a motivation section.
Chairs: consensus call
- Should draft-kempf-netlmm-threats be made only wg item
in order to satisfy the wg foal of a threats draft for
MN<->AR interface of NETLMM? Unanimous consensus.
Need to confirm on the list
V. Kent Leung: Design team update
- Goal: Meet the requirements specified in draft-req.
Identify components/functionalities of base NETLMM
protocol
Base NETLMM oslution draft originates by
either:selecting or from
scratch
- timeline: DT concensus by May
choose contributed I-D or create a new draft
as base document
write up in June
submit base NETLMM solution draft before ietf
66TH meeting
- AR-MAP end to end mapping,
- Components: MN identifier
Dynamic MAP allocation
message types for location update between AR
and MAP
Message transport (control plane)
Security between AR and MAP
Address assignment for MN
Support for any ip version host
data plane transport(tunnel, mpls)
ar-map reachability detection
ar handover(including release )
- Out of scope: MN-AR interface
inter-map handover
fast handover
hierarchical MAP
- Status: Deliberation on the topcis continuing
Need to write up summaries of topic conclusions
MN-AR interface sync up needed
Makesome progress in face-to face meetings
Protocol has not been decided yet.
Microphone comments:
Hesham: MAP term can be confusing
Kent: MAP has MIP function inside.
Hesham: it's changing mn-ar interface. put it into the
requirement.
changing behaivour in the host,
Kent: late presentation in the mn.
Alex: Tunneling has been decided between AR and MAP,
address assignment
Status between AR and MAP,
Kent: tunneling has not yet be decided, transport layer
, bear
transport,
Data address assignment statatus based , could be
DHCP
Vidya: Disappointed by changing host, suffering for
mobile node,
netlmm domain has two MAPs in one domain, confused
Kent: Each MAP serving prefix, mobile can anchor,
Vidya: MN attachment, could be 3gpp, 3gpp2 interface,
Kent: some layer 2 trigger,
Henrik: return back Hesham question, netlmm client in the
mobile node,
James: We have not yet talk about MN-AR interface,
focus on AR-MAP protocol, please wait.
[?]: Multiple MAP can serve same prefix
Kent: MAP redundancy, I am not sure whether it is in the
scope
[?]: Packet arrive map, ttl, same ip subnet
Kent: We have not addressed that yet, three hops, just
doing tunnel or
ttl
[?] Question about time line, May is possible, did you
describe the
performance in the goal, clarify question.
What's the time line for the DT.
Kent: it should not be outside the scope.
James: We already mentioned that, next ietf meeting.
Alex: Curious question, some trigger in mobility, is
that DNA, or DHCP?
Kent: trigger is TBD, API trigger
Vidya: small comment: netlmm and mip has same concern
about ttl.
SCTP and UDP are mobilty header?
Fast handover is not considered, AR-AR tunnel will
be goal here?
yes.
[?]: IPv4 is out scope,
[?] two way to support IPv4,
1) access network,
2) IPv6 access network with IPv4 address actually
last hop,
backbone network is netlmm,
Kent: transport ipv4 packet in NETLMM is possible
VI. Julien Laganier: host address interface of NETLMM
draft-laganier-netlmm-mn-ar-if-00.txt
based on draft-wood-netlmm-emp-base-00
- Approach: chosen a starwman netlmm protocol
- ARs advertise same off-link subnet prefix
- prefix is used for stateless autoconfiguration
- MN sends all packets to AR
- use DNA and SEND procedures
- quick failove rto new AR
- secure detection of MN handover
- use a single public key to generate all CGAs
- Remaining issue:
- SEND is acceptable
- Chose as default AR the one sending RA
- Do we use a single Ar link local address.
Microphone comments:
James: DNA, Layer 2 protocol talk with NETLMM protocol.
Greg: exisiting multicast neigh discovery, it's time to
talk with DNA.
James: AR listen to all multicast address,
David: RA subnet off link, application can know the
differences,
correlation with TTL,
Greg: We never advertise prefix offlink, rfc 2461 ND.
Vidya: Goal DNA is used?
James: example how layer 2 supported, it is just a example
how many people read the drafts: pretty good
WG CALL on MN-AR interface Draft: sould draft become
the only wg to
satisfy the wg goal of a draft?
Yes (many), No (1)
Need to confirm on list.
is there anybody IP version netlmm air interface?
People are making argument: layer 2 control mobile
node what to do,
where to go?
Vidya: 802.11i, I can choose trust IP layer,.
Alex: information /experiement?
James: Information
James: A couple of questions in the list, discuss in the
list.
VII. Conclusion
James: Thank you very much , run whole time.
James: If you are interested in interoperation test, please
come to me.
_______________________________________________
netlmm mailing list
netlmm ngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
|