[MEXT] IETF71 minutes

[marcelo bagnulo <[e-mail]>]

Hi, please find the minutes attached, let me know if you want changes

Mobility EXTensions for IPv6 (MEXT)

Minutes for IETF-71 meeting
====================================

Chairs:
Julien Laganier <[e-mail]>
Marcelo Bagnulo Braun <[e-mail]>

Scribes:
Gerardo Giaretta
Sri Gundavelli
Suresh Krishnan

Sessions:
WEDNESDAY, March 12, 2008
0900-1130 Morning Session I

THURSDAY, March 13, 2008
0900-1130 Morning Session I

Minutes:

- Status of MEXT deliverables
  Chairs

DSMIPv6: dealing with Pasi's comments. Still outstanding comments. Last
changes can be done when the revision is done for IESG

MCoA: new version after George's comments. New WGLC

AAA goals: new ID needed. After that send to IESG

RO for Personal Mobile Router: no WG draft yet. There is a possible
candidate but comments and reviews must be needed

RO for automobile: new draft accepted as WG item. Need more comments

RO for aircraft: finished the WGLC but good shape and the group can
start working on solutions

PD for NEMO: ongoing discussion to be discussed today

Solution for aircraft RO: work on solutions starts now

RADIUS MIPv6: new version to be discussed today

Analysis of use of MCoA: Monami6 document updated long time ago. No
input for now. Input needed. It deals also with multiple HoAs

Multiple Interfaces motivations and scenario: Monami6 document. Review
needed. Situation similar of the previous document.

Mobile IPv6 operation with firewalls: no WG item but output of a DT. To
be discussed today

MIB for NEMO: WGLC after IETF

Flow/Binding Policy: draft by Hesham accepted as a WG item. Still
waiting for the draft which will be available at the next IETF

Flow Binding policy format: no WG item yet. Two drafts should be merged.

Update of RFC 3775: several comments in the mailing list. A compilation
of all proposed items to be discussed today.

Home Agent reliability: authors say the document is ready. Most comments
received were editorial. The document will be updated

o Recharter items under discussion

One item needs more discussion, which is the p2p home link model.

- Home Link operation over p2p links
draft-sarikaya-mext-homelink-prefix-delegation-00.txt
Bechet

Prefix Management issue when the p2p link is a home link
CFG_REQUEST triggers DHCP signaling
Francis, Julien and Gerardo: no protocol work. How the HA gets the
prefixes is up to the deployment or the system architecture.
Frank: p2p model implies that there is a prefix per MN while in the
shared link there is an address per MN
Tom Taylor: people need to work on the problem and expose better the
problem to the WG

- MIPv6 home link operation in various SDOs
draft-devarapalli-mext-mipv6-home-link-00.txt
Vijay

Jouni presents the slides on behalf of Vijay.
MIPv6 used in other SDOs with some links designated as home links.
Booting up in a p2p link which is supposed to be the home link needs
some considerations
Hesham, Gerardo clarified that the home link detection is done comparing
the IKEv2 prefix and RA prefix
George: an informational document which explains how to do this without
requiring new protocol work
Hesham: OK with an Information document but no need for changes
Julien clarified that there is a p2p link which handles the routing.
There is no state at the HA, so the "HA" is just acting as AR and sends
the downlink packets to the MN
Gerardo: no need for service selection in the BU as there are already
solutions in the p2p link negotiation
George and Suresh: no need for protocol work, probably worth clarifying
Gerardo: an informational document describing how
IKEv2 MIP6_HOME_PREFIX is used to detect the home link. No specific
Jouni: no protocol work.
Ahmad: problem statement needs clarification.
Raj: the scenario is not clear and should be discussed in the mailing
list
George: write a charter paragraph which describes what the problem is
and discuss it in the mailing list

Next Step: George proposal

o MEXT Deliverables

- Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-06.txt
Ryuji

Several comments after the WGLC on version 5
3 remaining issues. WGLC on version 7 after this IETF
Sequence Number issue. Proposal: MN should manage the SN value for all
bindings
Enhanced RO: not clear if MCoA works with this. Additional review needed
Simultaneous Home and Foreign attachment: HA intercepts all packets and
decides to send the traffic directly to HoA on link or tunnel to CoA.
MN sets the H bit in the BID option for the interface in the home link
Julien: to get the L2 addresses, ND must be used and L2 headers should
not be considered for this purpose
Sri: how the packet is sent via the home link?
Ryuji: MN sends traffic to the HA
George: this is not modifying the proxy ND but some special treatment is
needed
Ryuji: MN is not defending the address on the home link
Sri: take this offline to check

SN issue is solved.
Enhanced RO: review needed
Simultaneous Home and Foreign attachment: text needed and then discuss
on the list

- Automotive Industry Requirements for NEMO
Route Optimization
draft-ietf-mext-nemo-ro-automotive-req-00
Roberto Baldessari

RO scenarios
Requirements
- separability: switching to RO is subject to policy table to avoid
unnecessary RO sessions
- security: MNP ownership should be checked against off-path attackers.
Requirement to be extended for better protection. Certificates can be
used
Marcelo, Hesham: saying there is a certificate assumes already a
solution
Julien: proof of ownership of the prefix may be a good wording
Francis: authorization of prefix is better than proof of ownership
- privacy protection. Exposing MNP must be limited to CE and nodes on
the path MR-CE
Julien: privacy is not the right term as HNP does not give information
of privacy
Marcelo: if you use a prefix to figure out how many times one is in a
foreign link, you have a privacy issue
Requirement will be rephrased
- multihoming
- efficient signaling. Text in the draft is outdated
- switching HA. Considered in ISO CALM. RO should not prevent it from
working
Marcelo: is this related to multiple HoAs?
Not clear. Needs to find out if it is different HoAs or not
William: is this for reliability of the HA or for the RO?
Marcelo: whatever RO solution it must be compatible with HA reliability
solutions

- NEMO Route Optimization Requirements for
Operational Use in Aeronautics
and Space Exploration Mobile Networks
draft-ietf-mext-aero-reqs-01
Wesley Eddy

Believed to be ready for WGLC
Changed requirement on loss to also require NOT duplicting packets
Biggest change in Security Requirement
Old was IPsec MUST be usable
New requirement is clearer.
Hesham: why is it safe to assume trust relationship between MR and
mobility anchor points topologically near to CNs?
Alex: Was it considered RO neighbor correspondent nodes?
It seems not desirable.
Marcelo: the solution can work with both CN and a box nearby. The
security requirements for this are stronger than the 3775 RO. No on-path
attackers are accepted.
Alex: this deserves further discussion on the list
Fred: interactions between the global routing and RO. Global RO may not
have a direct route. Can RO survive? One or two packets may be lost, one
being the BU
Wesley: BU may not go through but you can still use the HoA
Marcelo: there is a scalability requirement to not cope with global
routing
Fred: need a couple of weeks to look at this
Marcelo: we need to close this re document in the short term
Alex: need to empahasize that session continuity is provided via RO

Next Steps: document is in good shape. Comment on the next two weeks. A
new version will be produced.

- DHCPv6 Relay Agents and NEMO
draft-dupont-mext-dhcrelay-00.txt
Francis Dupont

Francis thinks neither of them can get consensus and that is why we need a
solution with relays. He Talks about the advantages of these
Francis has implemented DHCP code twice and know that relays are small and
straightforward. Putting relays at two ends is a nice way of 
encapsulating dhcp traffic.
He thinks it is a nice way of getting consensus
Julien points out that only one of the proposals uses DHCP
Francis says the other one can use a DHCP message piggybacked on a BU/BA
Julien does not see the point in optimizing PD. It happens rarely and 
not on critical path
George mentions that the good thing about this proposal is that there is 
no need to do
any protocol work. He thinks that the draft is unclear but can be fixed
Sri wants to compare this to the Thubert/Droms draft
Alex thinks the diff b/w this doc and the Thubert/Droms draft is the 
encapsulation of the
DHCP packets. He is not sure it can work
Francis is aware of someone who uses this.
Alex agrees that it is worth exploring as a solution
Behcet discussed this on monday at DHC Ralph mentioned that this requires
standardization.
Behcet posted 2 drafts on this issue and he seeks comments
  
Julien wants to know about the security of this mechanism
Francis mentions it is just like DHCP (no security). He mentions the 
DHCP auth option
Alex mentions that multicast and anycast are hard to secure
Francis mentions you can use IPsec
  
Ryuji wants to know how to configure the DHCP server on the relay
Francis mentions there is a list of servers configured on the relay
You can use an anycast scope (all servers and relays>ll scope)
  
Francis believes it is good to put a relay or a server on the HA
  
Ryuji says that the main diff between the Thubert/Droms doc is if we put 
the relay on the
MR. Maybe we can update the T/D doc.
  
Fred Templin is working on colocating the relay and server the same node 
in autoconf
  
Teco Boot agrees to update the T/D doc and then try to get consensus
  
Sri wants to know what happens after the tunnel disappears. How does the 
DHCP relay
work? Will the DHCP packets get routed to HA
  
Behcet thinks that the tunnel vanishes after the MR returns home
  
George wants to mention that once you deregister from the HA the 
prefixes obtained
from DHCP are gone.
  
Sri and George to discuss this later on the ML.
  
Sri wants to couple the eventual solution to the mobility signaling
  
Marcelo wants to know if the nemo pd draft can use the contents of this 
draft to fix these
issues?
  
Alex supports both the proposals. He thinks we are going too fast for 
the market and it
is too early to choose. Hence we can take our time.
  
Alex wants a list of solutions instead of just one.
  
Marcelo wants to pick just one.
  
Teco thinks that if the DHCP has to disappear with the tunnel, then the 
DHCP PD
is not an option.
  
Francis mentions the DHCP release message
  
Jari confirms Marcelo's view that we can do only one solution. if we 
cannot decide
we should do nothing. He wants to see some direction from wg
  
Behcet agrees with Jari but the authors are not present.
  
TJ (through Ryuji) wants to know why we cannot use dynamic dns for 
mobility?
  
Francis thinks DHCP PD should be based on DHCPv6
  
Julien thinks PD entails state keeping in the DHCP server. there is no 
choice
  
George mentions that DHCP-pd is used over lte, pmip and dsmip links 
  
Consensus for DHCPv6 prefix delegation - to be confirmed in the mailing
list.
Votes: 26 votes support for using DHCP based approah/ 2 votes support
BU based approach

- Guidelines for firewall vendors regarding MIPv6 traffic
draft-krishnan-mip6-firewall-vendor-03
Guidelines for firewall administrators regarding MIPv6 traffic
draft-krishnan-mip6-firewall-admin-03
All - 15 min

Nobody has read them
Marcelo gives the room 10 minutes to read and comment
  
Henrik wants to reduce timeout for the state from 420 sec to something
more reasonable
  
Jari thinks that the document is talking about generic IPv6 issues as well.
He wants to scope down the document and remove these things.
  
Marcelo and Sri want one document (not -admin and -vendor)
  
Suresh disagrees with them. He thinks the audience for the two documents
is different and hence they should be separate.
  
Henrik agrees with Suresh. It makes the documents clear and concise. He
thinks vendors like concise documents like the firewall-vendor draft.
  
Sri thinks it can be a section inside the combined document.
  
Henrik wants a smaller document focussed at SOHO router vendors
  
Jari thinks the merge/split document is not the right discussions. He 
wants to
discuss next steps
  
Marcelo wants to address Jari's comments to pull out general ipv6 stuff
from doc and then ask for adoption
 
- RADIUS Mobile IPv6 Support
draft-ietf-mip6-radius-04.txt
Kuntal

Radius MIP6 support skipped since there is nobody to present
  
- RFC 3775 update
Chairs - 15 min
     
DHAAD removal issue

Jari wants to see if the functionality has been implemented and used
if it is not, it is fine to remove
Gerardo thinks that we are removing something that has been outdated
by other work (e.g. bootstrapping work)
Jari thinks we need to also judge future interest
Alex knows about 2 implementations of dhaad
Alex thinks the scenarios for bootstrapping are different than those for 
dhaad
He wants to know if diameter has outdated radius, has ikev2 outdated ikev2
Gerardo clarifies that he did not mean bootstrap work was more advanced but
it is more adopted and used
Charlie wants this discussion to be done on ml
Sri has an implementation and does not want to remove
George agrees with sri to keep it but he wants the security implications 
to be
clarified
Jean-Michel mentiones IKEv1 is obsoleted by IKEv2
Alex does not care and thinks people will still use IKEv1
Jari thinks there is support to keep in the doc
Marcelo wants to have some diff text about the security issues
Sri wants to leverage existing text
Alex mentions there is already language in rfc3775
Jean-Michel sent some text to ML and Alex agrees with it
  
BA/Berr sent by HA
  
Alex and Ryuji think HAs can already send BRR/Berr
Jari thinks that binding errors can be sent by both HAs and CNs. He also
thinks that this was the intent and the text in RFC3775 is unclear about 
the
term CN
Jari and Alex need to agree about BRRs
Deng Hui needs clarification since he faced the problem with HA switch
messages
  
Returning home
  
Sri agrees to switch SHOULD to MUST
George wants to keep the SHOULD. He wants the capability to decide
when to send
Sri and Jari mention it is a MUST when the node wants to start using
its home address
The chairs will accept new issues for 3 months and then try to close them
Henrik wants all the issues to be tracked in the issue tracker
  
 
o New Charter Items

- Binding Revocation for IP Mobility
Ahmad Muhanna presented by Sri

Jari has reviewd the document and is fairly in a solid shape. However,
the document is written with more focus on the usecases. Authors must
publish the new document and fix it

Sri agrees that the document needs to be restructured, says that the
authors planned to define the mechanism in a generic way and list some
examples at the end  
  

- Generic Notification Message for Mobile IPv6
Sri  

Henrik asks why this draft is not listing the most obvious example that
is Revocation use case in the examples for this mechanism and why there
is a seperate draft for Revocation

Sri answers that we dont specify receiver action in generic notification 
mechanism
Revocation requires specification on the event peer and requires more
focus.

Sri mentions that  also, notification mechanism provides a generic 
container for
all events. We should not use up the MH number space for every event
and so we need to define a number space for one MH type.

Sri mentions that some people suggested that the revocation mechanism should
make use of the number space from the notification draft

Gerardo says that then it is ok if Revocation uses one of the sub-type

- Virtual Home Link configuration for Mobile IPv6
Sri
  
Hesham thinks anycast is no different in v6 than in v4. He thinks the 
only difference
is a reserved prefix in v6 for link specific anycast
Ryuji mentions that rfc3775 assumes that prefix is a /64
Vijay thinks that there is a specific prefix reserved for DHAAD anycast
Suresh mentions that it is a reserved interface identifier and not a prefix
Discussion to continue on list
Acee wants to know if this doc will be informational
Sri thinks so
  
- Extend DSMIPv6 Home Network Support
George
  
Domagoj wants to know about the usage scenarios. e.g. v4 HoA as the CoA
for the v6 HoA

o Other topics

- Alt-CoA check
draft-arkko-mext-rfc3775-altcoa-check-01.txt
Jari

Hesham is neutral to this change it is good because this can be enabled and
disabled on the receiver based on the info in the BU
Jari mentions that text changes needed to FMIP and have been made
Jari mentions fmip has a more specific rule for alt-coa handling FMIP
Ryuji mentions that MCOA does not use Alt-CoA and so there is no 
conflict b/w
this proposal and monami6 work but Jari thinks the problem still exists
Do we trust the node to just check one of the addresses in the packet?
He has not thought much about this yet
Sri wants to know if there is a configuration knob
Jari mentions that it is tuned on by default but can be turned off
Ryuji wants to mention whether the src address or alt-coa will be used 
by the HA
Christian wants some kind of negotiation between the HA and the MN to 
see if
it is turned on
Jari does not like to have negotiation
George mentions there is no point negotiating with a potential attacker
Alex wants more granularity (per HoA basis)
Jari wants to take some time to see if we can accomodate the mcoa stuff 
in this
doc within say 3 months
  
- Residual threat analysis
draft-haddad-mext-mip6-residual-threats-01.txt
Geroge

George solicits more inputs on threats
Francis thinks attacks are very easy if we are attached to multiple 
links (at least
one of the valid CoAs is used)
Julien wants to know how CGA helps
Suresh mentions that it prevents flooding a specific address but not 
flooding a link
Jean-Michel wants to know if the work takes into account the work done 
in sava/savi
Marcelo wants to document the threats first and then decide what to do 
with them later.
The scope of the work is threats that are SPECIFIC to mipv6
Hesham wants to know about ingress filtering stats
George mentions that we can create optional mechanisms that only 
paranoid people
turn on
Christian Vogt mentions 25% of internet addresses can be spoofed and 
savi wg is
more limited only source address validation on local link
Francis mentions that there are attacks that do not use source addresses 
and they
cannot be covered by ingress filtering
Marcelo wants to cover all cases not just CoA address issues
Jari wants to focus the document without making huge claims
Jari mentions that the relationship between the HA and Mn is traceable. 
Anonymous
HAs would be a good idea but they do not exist
George mentions that the device can be traced, but not the user e.g. SIM
Jari mentions that a SIM can be traced to a user
George says not in Europe
Jean-Michel says that is not true in France
George says we will not do this for France.
(laughter)
Jari mentions that this work might have an effect on MCOA and hence we 
need to
analyze the effects
  
- Simultaneous Mobility Problem Statement
draft-wong-mext-simultaneous-ps-00.txt
D. Wong
  
Hesham wants to know whether we are documenting or trying to solve
Francis mentions that rh + hao as suggested is worse than tunneling and 
is a
security nightmare
Suresh mentions that he and Wassim had a draft 4 years ago that dealt 
with the
same issue and there was no interest in solving it. It was called 
Binding Update
Backhauling.
  


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext