[Int-area] meeting notes

[Jari Arkko <[e-mail]>]

Here are the meeting notes. Please send corrections and additions to the 
ADs. Thank you Ed for the notes!

Jari

----------------

intarea Agenda - IETF 76
1300-1500 2009-11-09 (Mon)
(Last revised 2009-11-09 08:37 AM ET)
-------------------------------------

Administrivia Arkko/Droms 10 minutes
Agenda bashing; blue sheets; scribe; Jabber scribe
http://www.ietf.org/proceedings/09nov/slides/intarea-3.pdf
note well, agenda bash
Working Groups update
DNA, PANA to be closed
6man – UDP checksums discussion should be interesting
NETEXT discussing BOF outcome
6lowpan – ND extension
A lot on IPv4/IPv6 coexistence in several groups
Wed 13:00 AplusP BOF, address sharing through tunnel deployment
3GPP-IETF joint meeting on IPv6 cellular, March 2010; are the current 
models sufficient for cellular operators? Tools in development and new 
tools to be considered. Opportunity to work together.
Any other WG chairs have anything? No takers
Intarea “working group” formation – dual role as discussion forum and 
secondly to advance work items in the IETF. Typical WG organization with 
two co-chairs, looking for volunteers
Alain Durand – is this WG the right place to discuss issues arising in 
the Intarea with impact on other areas (eg Application)?
Jari – definitely one of the forums
Alain – cross-area discussions may be needed
Ralph Droms – this has happened in the past, discuss the same draft 
multiple WG meetings, area meetings
Jari – surface to all the right areas.
Fachure – this would be a good group to discuss broader questions
Mark Townsley – don’t lose the opportunity to maintain the open intarea 
area discussion – important to AD to hear this stuff. Don’t delegate too 
much away to intarea WG
(chairs agree – intention is to maintain focus on area-wide concerns)
Intarea WG work items
New work should satisfy some basic conditions, setting a high bar. Not 
“abandoned work” from “failed BOFs” but important work affecting the area
Initial milestones: IPID doc and tunneling issues

Issues with IP Address Sharing M. Ford 20 minutes
<draft-ford-shared-addressing-issues-01>
http://www.ietf.org/proceedings/09nov/slides/intarea-0.pdf
repeat of presentation in Softwires
from SHARA BOF, merged several prior efforts
Corral all the various issues in solution docs, capture common issues 
into one citation
Taxonomy: CGN vs port-range solutions
Long tail of subs requiring more than median number of ports, need to 
balance sub/address ration; manage port churn; implications for logging 
and signaling
Breaking applications that care about ports; typically ALGs used
CGN has limited ALGs available, port-range solutions require changes to ALGs
ICMP problematic.
List of other issues, some needing more contribution (multicast in 
particular)
Behcet Sarikaya – address sharing and mobile IP at AplusP BOF
Charles Perkins – working on a solution that works around some of these 
problems
Ralph – this is the taxonomy of problems, not solutions
Security issues discussed including restricting port range (less port 
randomization), impact on logging and “penalty box” extend to include 
ports; spam blacklisting
IPsec through NAT is applicable; authentication based on only IP address 
no longer works
Joe Touch – port randomization is not security; limiting concurrent or 
sequential connections (within timeout) 3 bit per host – 8 connections
Sam Hartman – let’s make sure port randomization is important before we 
spend any time on it. IPsec connection latching – a way of naming for 
upper layer protocols to use; may be port sharing implications, please 
double check
Joe Touch – unsigned Diffie-Hellman; binds up and down. Multiple 
identities per port?
Ralph Droms – author is happy to accept text
Geo-location and proximity; reduced confidence and granularity
Traceability – legal implications; log source address and port and 
timestamp to unambiguously identify subscriber; large volume of data for 
long-term retention of mappings
Any additional issues?
Alain Durand – can we get Transport input? Multipath TCP, etc. need 
input/text from them; what do we break? Maybe good idea to present in 
TSVarea
Kenji Rikitake – if large number of CPE, there are allocation strategy 
problems; scalability and complexity
Joe Touch – control block sharing, congestion control, based on IP 
address; is there IANA impact from port sharing
Ralph Droms – unilateral deployment of address sharing has impact on 
other unrelated entities – you can create problems for others
Mat – yes, this needs to be addressed
Ralph – communicate with Mat on text, comments, etc. not sure where to 
home this
Alain – Softwires may be the home
Jari – probably reasonable to home it here, but not calling yet
Alain – don’t wait until next meeting to adopt in a WG
Jari – we can do on list in the interim

IP Router Alert Considerations and Usage F. Le Faucheur 15 minutes
<draft-rahman-rtg-router-alert-considerations-03>
http://www.ietf.org/proceedings/09nov/slides/intarea-1.pdf
Accept as WG work item (assuming intarea WG is formed)?
Problem Statement – Router Alert Option security concerns not well 
documented; practical questions remain to be answered – should RAO be 
allowed or blocked?
This would be a BCP to document the concerns, identify where RAO is 
appropriate or not; implementation guidelines
This is not about redefining RAO – document the current situation; see 
narayanan draft
Doc changes
Recommendation on not using end-to-end RAO generalized; illustrations of 
the flows that are/not recommended
Within an Administrative Domain is OK – safe
In water-tight overlay model – also safe – no leaking of RAO over domain 
boundary
Proposing this as a WG document, not enough review yet
Suresh – not progressing the hop-by-hop doc, no clear way forward
Sam Hartman – talk a lot about security, is this more than DOS?
Francois – mainly thought about DOS
Sam – does describing this as security issues really add clarity to the doc?
Ralph – assuming an Intarea WG, should this be a WG item? Consensus yes, 
to be confirmed on mailing list
Margaret Wasserman – does this doc meet the other criteria for a WG doc, 
that was previously put up?
Jari – seems there is enough contributors/reviewers and demand for this, 
please comment if you feel if doesn’t meet the criteria


Traffic safety applications requirements C. Cano 15 minutes
<draft-karagiannis-traffic-safety-requirements-01>
Vehicular networks emerging, initiatives going on in US and Europe
Can these performance requirements be met by IP based network and 
transport solutions?
Traffic safety applications
applications and use cases quite similar between US and European 
consortia; performance requirements differ
is this work interesting? Is IP an appropriate solution to these 
requirements?
Charles Perkins – difficult security issues on vehicular communications; 
what is the security architecture? Analyze the security requirements 
before deciding IP is the right solution; document would not be complete 
enough without the security analysis
Ralph Droms – are there security standards/requirements from the consortia?
Yes
? – why is this in the Internet Area? This is application or L2 problem?
Implication that some IP functions may need to change, e.g. ND too slow
Ryuji Wakikawa – requirements in this doc derive from SDO; governments 
assign frequencies for the v2v communication; did not pay attention to 
the network, VSC is single hop. Looking for feedback from IETF.
Brian Carpenter – this would be a good item for MANET; how quickly are 
these consortia going to decide on a network? If they are prepared to go 
through several years of SDO liaison activity we might be able to 
contribute, otherwise we should wash our hands.
Jari – we’re not here to design everyone’s networks; not clear what we 
should be doing here. This may not be the right forum.
Ralph – what is the timeline?
Wes George – is this interesting? Yes. IETF can help with this. Can IP 
solve the problem? Yes, but need to identify gaps. Lack of reference to 
IPv6 – sensor net, smart grid also similar omission
Francois – C2CC is considering only IPv6
Thierry Ernst – car manufacturers don’t buy into IP for car safety; SDOs 
are considering IPv6 – liaison is necessary; why Intarea – interaction 
between MEXT, not just mobility issue, address management, etc.
Ralph – collect interest and comments

The Subnetwork Encapsulation and Adaptation Layer (SEAL)
F. Templin 20 minutes
<draft-templin-intarea-seal-07>
Accept as WG work item (assuming intarea WG is formed)?
http://www.ietf.org/proceedings/09nov/slides/intarea-2.pdf
tunnel MTU – how to determine? How can the tunnel adapt to restricted links?
SEAL adds a 4 byte encap sublayer; tracks MTU without PMTU discovery
Works like IPv6 fragmentation, with fix segment size and not overlapping 
segments
No prior negotiations needed
Draft status – lots of list input, changes made
This is a standards track submission through intarea, vs experimental 
RFC on SEAL-FS (fragmentation sensing)
The MTU is based on Egress Tunnel Endpoint (ETE) maximum reassembly 
size, not on the minimal link
Unmitigated fragmentation considered harmful, but carefully managed 
fragmentation is useful. In-network fragmentation is “canary in the coal 
mine”
Margaret Wasserman – wrote review of the doc, need a larger answer – 
already a ton of tunneling protocols, who needs this and for what?
Fred – SEAL focuses on the encapsulation format; companion draft on VET 
covers the end-point negotiation
Margaret – why do we need yet another?
Fred – sequence number and MTU amelioration
Margaret – not convinced
Jari – if no one knows what this is used for
Alain Durand – if we had this years ago, it might have been helpful. Now 
it is too late, cat is out of the bag. Yet another
Fred – well recognized that MTU is an issue in tunnels;
Mark Townsley – what is the target status? Inventing a protocol is not 
hard; getting it deployed, mindshare, etc. is really hard. Publishing 
this as experimental/informational is a good idea, putting it into 
practice, code first – then standards track.
Fred – an attempt to make tunneling a first-class citizen
Mark – this is only a piece of a piece of what could be a first-class 
citizen; a new tunneling protocol attempting to obviate the rest becomes 
an n+1
Fred – there is a scenarios doc (RANGER) as well
Jari – do you (mark) foresee using this? No.
Margaret – many tunneling protocols are being developed, and don’t seem 
to be adopting this; that is worrisome. Maybe there are specific 
objections or they feel they can solve it more simply.
Jari – it is clear there is a problem with MTU in tunnels, not clear if 
this should be the solution.
Mark – big difference between “is this interesting, and you might use” 
versus “are you planning to use it”
Jari – if people don’t see using it, why take up the effort? Take on the 
mailing list

Lightweight IGMPv3 and MLDv2 Protocols R. Bonica 10 minutes
<draft-ietf-mboned-lightweight-igmpv3-mldv2-06>
(Ron not here)
Jari – need review here please take a look.

Other WG issues, new business, etc. Arkko/Droms 10 minutes
-----------
120 minutes