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

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