Agenda bashing (Jari) -------------- IPv4-IPv6 co-existence work (Jari) --------------------------- Jari presents. IETF Interim -- Malta (Jari) --------------------- Jari: Raise your hand if you plan to attend the meeting and haven't raised your hand in behave: 1 Raise your hand if you plan to attend remotely if you haven't raised your hand in Behave WG: 2.5 Charlie: We have general meeting already and that adds more travel requirements.... Unknown: Have we considered adding more time to an existing meeting? Mark: We did that already on Friday. Jari: Do I have to be away two weeks from home. Pete: There are two jabber participants that would like to participate remotely. Tunnel Issues (Joe Touch) IPv4 ID Uniqueness (Joe Touch) ------------------------------ http://tools.ietf.org/html/draft-touch-intarea-ipv4-unique-id http://tools.ietf.org/html/draft-touch-intarea-tunnels Update on drafts, request for feedback - Relationship to tunnel security = separate vs. integrating = don't want a 500 pg document - IPv4 ID Uniqueness = If the source has NOT fragmented the packet, should "ignore" the IPv4_ID field = Updating document as standards track! = Brings IPv4 ID in line with IPv6 frag field = Including context & implications = Fixed IDs already occurring (e.g. cellphones) = Can't reuse unused bits = May help ROHC if known = Can't rely on fields being unique if wrapped. Suresh: Thinks the v6 way is one thing, but in v4 there's an ID that makes it easier for a node to fragment Joe: V6 does only frgamentation on end-point. There's no good reason to do it different from v6 since we're trying to transition. If you do fragmentation in the middle there's a risk that receiver reassemble fragment that are not from the same packets. We suggest to use similar mechanism as PMTUD / ICMP packet too big. Fred Templin: The ID serves as some sort of nonce. In the ICMP error you might only get back 8 biytes of the transport header that wouldn't let you figure out which packet triggered the error. Joe: Already many stacks send back as many bytes as they can in the ICMP error. Jari: With the tunneling doc we need more reviews before we can send the document for publication. Security concerns with tunneling (Dave Thaler) -------------------------------- http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-security-concerns http://www.ietf.org/proceedings/08jul/slides/v6ops-5.pdf Earlier discussed in the context of Teredo, but this is actually a more general problem. - Started off to be about Teredo, even before Dave got to it. - As of Dublin, it was no longer even a v6ops document, but since the update did not happen that is still in the name. - Security devices often do packet expectation. - "If" tunnels bypass the mechanism ==> admins hate them - Admin preference: don't automatically "tunnel through" a "managed network". But how dow we know? - Terminating at the boundard of a managed network is O.K. - Should prefer native functionality (?vs. tunneled funct?) - How can the tunneled data packet be identified? = protocol #/port #/tunnel server addr.(!)/do the work [but these can produce false positives, ...] - Not dropping is seen to "increase the exposure" of, say, the firewall - Exposure of a NAT hole = NAT mappings kept stable means more discoverable = External address/port may be easy to learn from the client's inner address which may be in DNS, p2p, etc. = Tunneled packets seen by more parties (on average) - Public Tunnels "widen holes" = some devices only allow packets from previous destinations = may eliminate the "need" for the attacker to spoof = recommend only when needed = consider whether should do stateful filtering - Guessing addresses (v6 is usually harder) = but well-known addresses = try to use popular server addresses (google) = some address bits are ususally the same - Profiling targets = knowing host platform helps target attacks = e.g., knowing if NAT is a Cone NAT. = This applies to MAC-generated addresses - Source routing [RFC 5095] - Mark: Combine with Joe's document? - Joe Touch: could be sent as a pair. There are other security considerations that are needed and not in Dave's document. You might tweak the title, because it really has to do with devices on the ingress and the egress interacting with the tunnel. - Brian Carpenter: draft is a lot more negative than the talk; could be used as an excuse to block a lot of IPv6 tunnels. - Mark: maybe we also need how to make tunnels work, not just what is wrong with them. Tunnel Loops and Its detection (Mohana) ------------------------------ http://tools.ietf.org/html/draft-ng-intarea-tunnel-loop-00.txt A new issue, brought up in the mobility context but also a generic issue. -