[Int-area] Re: notes from the INT meeting in Montreal

looks good to me.

Vijay

Jari Arkko wrote:
> Thank you Stefano and Vijay for taking notes! If there
> are any additions or corrections, please send them to
> either me or Mark.
> 
> ---
> 
> Internet Area Meeting
> IETF 66, July 2006, Montreal
> 
> Area Directors: Jari Arkko & Mark Townsley
> Note takers: Vijay Devaparalli and Stefano Faccin (merged and edited by
> Jari Arkko)
> 
> 
> 1. Area status update (ADs, 20 min)
> ===================================
> 
> BOFs: none this time, shared interest with HOKEY BOF and the NEW
> BOF. LIES/TERNLI BOF did not happen, but there will a presentation on
> this topic later in this meeting. One BOF on anycast was discussed,
> but there was some discussion on O&M open area meeting.
> 
> WGs creation, rechartering, and termination: Created ANCP (Access Node
> Configuration) and 16ng (IP over 802.16) WGs. Terminated IPOIB (IP
> over InfiniBand) due to having finished its main task. MIBs remained
> in their charter, but there was not enough progress on them.
> 
> MIPSHOP rechartered after it had finished all of its tasks. MIP4
> being rechartered to add dual stack operations work item. MIP6 being
> rechartered to consider progress and align to current interests and
> the charter. NEMO and SHIM6 will undergo rechartering before IETF-67.
> HIP is rechartering for new items and will close thereafter. IRTF HIP
> WG remains.
> 
> 2. Other WG news:
> =================
> 
> 6LOWPAN needs to finish its 2 current deliverables (an is a year
> behind) and wants to address new topics.
> 
> IPODVB working on L2 security mechanisms that need to be revisited
> based on current charter.
> 
> PANA: explosion on the IETF discussion mailing list based on initial
> e-mail from Sam Hartman. This has led to an effort in the WG to reduce
> complexity of solution since there is considerable confusion. "Less is
> more".
> 
> NETLMM has published its first solution draft from the design team,
> and will have interim meeting in September.
> 
> 3. Area documents status
> ========================
> 
> These documents do not have a home in any WG.
> 
> draft-fenner-iana-exp-2780-02.txt: Experimental allocations for
> various IP layer numbers. Approved, in RFC Editor’s queue
> 
> draft-bagnulo-cga-ext-01.txt: Extensions for CGA needed for SHIM6
> work. Approved, in RFC Editor’s queue
> 
> draft-bonica-internet-icmp-01.txt: Extensions to add data objects to
> certain ICMP messages. Still ongoing discussion, PS vs. EXP and IPv6
> issues. Will be discussed today.
> 
> draft-bagnulo-ipv6-rfc3480-update-00.txt: Updates to RFC 3484 to
> support multihoming, plus a few other minor updates. Will be discussed
> today.
> 
> draft-laganier-ipv6-khi-01.txt: An allocation from the IPv6 space to
> support HIP implementations that depend on unmodified APIs. Main
> discussion issue about the size of the allocation is now
> resolved. Will go ahead as an AD sponsored Experimental RFC.
> 
> 4. IAB Routing and Addressing Workshop
> ======================================
> 
> Dave Meyer pointed to a mailing list (routing-discussion) for
> discussion on routing and addressing. There is going to be an
> IAB-organized workshop on operational problems and future challenges.
> 
> The plan is come away from the workshop with a problem statement on
> routing operational issues, not to design a solution. Workshop will in
> mid-October, time and place to be narrowed down (participation by
> invitation).
> 
> 5. Source address selection problem for multi-homed environments
> ================================================================
> 
> http://www.ietf.org/internet-drafts/draft-bagnulo-rfc3484-update-00.txt
> 
> Marcelo Bagnulo presented issues which if need to be solved would
> required updating RFC 3484.
> 
> The goal of this presentation was to agree if RFC 3484 needs updating,
> and to provide input on Marcelo's multihoming issues.
> 
> A set of issues in RFC 3484 was identified: remove site-locals,
> include ULAs, additional tools for policy table handling, handling of
> unreachable source addresses (identified in SHIM6 and previously in
> MULTI6; needed for multi-addresses nodes and sites, and can help with
> ULA cases). Document suggests a set of rules that provide guidance to
> the application when it selects the src add, similar to the available
> for dst add selection; also, a modification to the src add selection
> of the IP layer, so that unreachable source and destination address
> pairs are detected and alternative address pairs are tried.
> 
> Dave Thaler - Agrees with working on modification to the source
> address selection
> 
> Pekka Savola - Surely we need do the second part, not sure about the
> first one. Marcelo: For first part intention is to include very lax
> guidance to the application developers. Pekka: No changes in the
> implementation? Marcelo: There would be changes in the application.
> 
> Tim chown - Would like to see these changes happen.
> 
> Unidentified - It is complicated currently with socket API to do source
> address selection. Are you proposing TCP connect to do source address
> selection? Most applications should do it by themselves today.
> 
> Unidentified - In case of UDP it can be even harder to do. Marcelo agrees.
> 
> Pasi Eronen - in Windows Vista there are solutions for this. There is
> exposure to the applications. Marcelo points out that there is also
> connectbyname call.
> 
> Dave - Confirm that it is true. API changes are better than having
> applications deal with multiple addresses and make decisions.
> 
> Hesham - Agrees with the problem. Asks if we have an idea what is
> important to solve first? There is a need to prioritize.
> 
> Bob Hinden - the current IPv4 document is a compromise solution.
> This can be get complicated very quickly. I would rather with
> document solutions that actually work from vendor and deployment
> experience rather than trying to develop new solutions.
> 
> Unidentified - Is SHIM6 as solution for this? Marcelo responds that
> SHIM6 requires both ends to be updated, but here we are saying that if
> you are multihomed and have two prefixes, there is the need to update
> a large number of nodes. There should be simpler & more efficient
> solutions available.
> 
> Jari concludes by stating that there is interest for this work. But we
> should be careful in not doing too much or too radical
> solutions. Focus on what implementations already do.
> 
> 6. Making CGAs survive hash algorithm issues
> ============================================
> 
> http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-00.txt
> 
> Goal of the discussion is to note that RFC 3972 had a hard wired hash
> algorithm. Should we change that?
> 
> Marcelo Bagnulo notes that there is an issue with recent attacks
> against collision free hash functions. These challenge the application
> of such hash function for the provision of non-repudiation
> capabilities. For SEND, the idea is not to move from SHA1 but to allow
> other hash functions. In order to avoid downgrading attacks, encode in
> address itself. Use Sec field to encode both current Sec information
> and the hash function used, reserve 3 values for existing, and create
> new registry CGA SEC for the future
> 
> Iljitcsh - why is it necessary to carry the hash function in the
> address? There are other parameters that are needed anyway. Why not
> have this information stored there? Marcelo responds that this is to
> prevent downgrade attacks
> 
> Pekka Savola - This might be a useful direction to go. But may not be
> needed now. The current SHA1 function is quite secure. I would be a
> bit hesitant to do it now. Marcelo notes that today there is not much
> deployment of CGA. We want to reserve bits today, before deployment
> happens. Once it happens, its too late to use the same bits. And there
> are no other bits available.
> 
> Gabriel - Supports this.
> 
> Discussion continues about whether other parts of the CGA idea, such
> as the used public key algorithm, need to be protected in the same way
> at the same time. Tim Shepard notes that with the public key
> algorithm, there is no problem with downgrade attacks. But with the
> hash algorithms there is a possibility of downgrade attacks and so
> should be encoded in the address itself. For public key algorithms
> this need not be encoded in the address
> 
> 7. Way forward with ICMP extensions
> ===================================
> 
> http://www.ietf.org/internet-drafts/draft-bonica-internet-icmp-02.txt
> 
> Goal is to get a feeling from the group on where we stand on the
> problems remaining on this discussion, such as IPv6 support. Jari gave
> an update of the history of this proposal. An early version of this is
> actually deployed out there. Can we have an effect on that deployment?
> Remaining issues are:
> 
> o Standards track or experimental?
> 
> o Given that we are doing for IPv4, should we do for IPv6? One
> implementation already exists that does this for IPv6.
> 
> Joe Touch - Does not care if others do some bizarre extensions
> to ICMP to support some sub-layer 3 protocols. maybe we shouldn't
> do anything.
> 
> Mark - we are re-opening the original debate. we don't want to
> go there.
> 
> Joe - but you are trying to justify the work using the deployed
> based as the reason.
> 
> Mark - Lets not re-open the earlier discussion.
> 
> Jari - Earlier we did a separation to the base and the application of
> this. ICMP traceroute for MPLS is one application. No question about
> that. But there has been other proposed applications, so we may need
> this for a number of purposes down the road.
> 
> Pekka - there is an Internet layer implication by this change.
> Supports proposed standard.
> 
> Rob Austein - IPv4 and IPv6 versions of ICMP should be similar.
> What was decided for IPv4 ICMP should be done for IPv6 ICMP too.
> 
> Bob Hinden - This is probably going to show up in other places
> (3GPP, Wimax). So not sure doing a special case of MPLS is a
> good idea. There should be general solution if at all any.
> 
> Mark - The MPLS objects are themselves advancing in the MPLS
> working group. We are doing a more general solution here that
> will be useful for more than MPLS.
> 
> Conclusion by Mark - Heard a few people say the solution for IPv4 ICMP
> and IPv6 ICMP should be similar. This seems like the way to go.
> 
> Jari - Should this go on standards track or experimental?
> 
> Hum - Mild preference for standards track.
> 
> 8. Comparison of mobility protocols
> ===================================
> 
> http://www.ietf.org/internet-drafts/draft-thaler-mobility-comparison-01.txt
> 
> Goal: Increase awareness of where the different schemes are in terms
> of their functionality, efficiency, etc.
> 
> Dave Thaler presents his analysis on MIP6, SHIM6 and HIP. The
> analysis is based only on WG drafts.
> 
> Vijay Devarapalli - Is network outage part of IP Mobility problem? Dave
> - Maybe.
> Geoff - It is the rendezvous mechanism that is important to consider.
> not network outage.
> 
> Margaret - What would be interesting to compare between MIP and shim6
> is where things happen. In mip6, the knowledge of about HoA and CoA is
> on the home agent and in shim6 it is at the end hosts. There are some
> architectural differences. Dave - True. But only wanted to see what
> problem each protocol solves and what features are easy to compare.
> Hesham - There are architectural differences, but there are two modes
> in MIP6. route optimization is between the MN and the CN.
> 
> Tim Sheppard - How you fill in the boxes reflects some
> architectural assumptions. Want to tease out the assumptions.
> IPsec VPNs?
> 
> Pekka - Home Address are as stable as the home link. Subject to
> home re-numbering. Vijay - There are extensions to MIPv6 to handle home link
> renumbering and home address change. In the event of home address
> change the FQDN to HoA mapping is updated.
> 
> Alex - Include reachability from behind a NAT? Dave - Limiting this to
> IPv6 only. Assumes no NATs
> 
> George - You should compare MIPv6 route optimization to shim6
> and HIP, since that is end-to-end. Dave - agrees
> 
> Hesham - There are WG documents in MIPSHOP that reduce the number
> of MIP messages. Dave - Send me the information.
> 
> Thomas - Puzzled by the connect overhead. with MIPv6 you can send
> packets right away if using the tunnel with the home agent. Route
> optimization kicks in later. Dave agrees.
> 
> Andre - DoS protection? Dave will consider this
> 
> Vijay - Do you want to consider maturity and deployment experience
> of these protocols in your draft? Dave has not considered these. Only
> a technical comparison.
> 
> George - Make it clear that you are considering these protocols
> end to end. There is a home agent (reverse tunnel mode) that is
> very different. Dave agrees
> 
> 9. Transport - network layer interface evolution and mobility
> =============================================================
> 
> Goal is to talk about the challenges related to transport - IP
> interaction, particularly related to implications of mobility
> technology. Discuss, and gather input for a BOF in this space in
> IETF-67.
> 
> Lars Eggert goes over the problem space.
> 
> John Loughney - Traditional transport protocols assume a uniform path
> through the network that does not change often and the RTT remains
> nearly the same. They have to now deal with rapidly changing paths due
> to mobility. Very significant when the RTT for the path changes.
> 
> Geoff Houston - It is important to see how the feedback is handled
> rather than how the feedback is given to the transport protocols. The
> issue tends to be architectural. What are you trying to do with with
> the feedback you receive?
> 
> Lars - agrees. But there is energy in the IETF because we see
> people wanting to work on this. Geoff points out that we need
> to require not just energy, but also validity of the approach.
> 
> Hesham - Transferring information from one layer to other is
> extremely useful. We need to be conservative on the type of
> information we transfer, though.
> 
> Thomas - Worries about folks coming with focused on specific link
> layers. There is an extension to Mobile IP for the home agent to tell
> the other end the path has significantly changed. Have a critical
> mass of people to work offline and come back with a problem statement.
> 
> Unidentified - Should not try to do the same thing in many different
> layers. We dont want two layer to interact to a change in the path
> that conflicts.
> 

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area