[13:10:58] --- venaas has joined
[13:11:06] --- venaas has left
[18:19:52] --- ks has joined
[18:20:03] --- iljitsch has joined
[18:20:11] --- dthaler has joined
[18:20:28] --- petrescu7 has joined
[18:20:54] <petrescu7> folks here may be interested to know that
[18:20:54] --- peetu has joined
[18:20:58] <petrescu7> some slides are at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[18:21:18] --- hartmans has joined
[18:21:39] --- hartmans2 has joined
[18:22:19] <petrescu7> search for 'intarea' in that page finds "Agenda", "Multiple encapsulations", "New work on SeND", "IP mobility security analysis", "What's in a name"
[18:22:21] <iljitsch> what's up with the audio? doesn't seem to work...
[18:22:35] <petrescu7> slide: Agenda, Part I
[18:22:52] <petrescu7> don't know, who should I ask
[18:23:05] <petrescu7> slide: Agenda, Part II
[18:23:32] <petrescu7> slide: Bof Status
[18:23:59] --- lars has joined
[18:24:11] <petrescu7> slide: Area Document Status
[18:24:16] --- bnsmith has joined
[18:24:25] <petrescu7> slide back to Bof Status
[18:24:34] <iljitsch> Well, if there isn't any audio I guess I get to go to bed at a decent time after all.
[18:24:46] <petrescu7> :-)
[18:24:53] <petrescu7> people hear ok in the room
[18:25:06] <petrescu7> I can ask on th emike this audio thing if you wish
[18:25:27] <iljitsch> i guess it's the stream because it just doesn't play at all
[18:25:29] --- jasso1 has joined
[18:25:35] <iljitsch> no never mind it will take too long.
[18:25:39] <petrescu7> checked the IETF list?
[18:25:50] <petrescu7> slide: Documenting Legacy MAP Methods
[18:26:26] --- nm has joined
[18:26:26] --- iljitsch has left
[18:26:29] --- dudi has joined
[18:26:39] <dthaler> s/MAP/EAP/
[18:27:54] <petrescu7> slide: "Area Document" Status
[18:27:55] --- arifumi has joined
[18:28:02] --- lars has left
[18:29:12] <petrescu7> slide: Documenting Legacy _E_AP Methods :-)
[18:30:39] --- rbless has joined
[18:31:24] <petrescu7> Bernard
[18:31:36] <petrescu7> Bernard Aboba BA
[18:31:44] <petrescu7> slide: multiple encapsulation methods
[18:31:48] <petrescu7> slide: outline
[18:32:00] <petrescu7> slide: History
[18:33:07] <petrescu7> slide:PPP
[18:33:47] <petrescu7> slide: Implications of Mixed Environments (From RFC 1042)
[18:34:38] <petrescu7> slide: Recommendations from RFC 1122
[18:35:25] <petrescu7> slide: What We Learn from History
[18:36:23] <petrescu7> slide: Questions for 16ng
[18:36:55] <petrescu7> slide: Feedback?
[18:37:03] <petrescu7> Andrew something
[18:37:25] <petrescu7> A: ATM encapsulations? correct slides 1577 specified use of ... encapsulations, so ther wa s only 1
[18:37:33] <petrescu7> BA: multiple choices that doc had no?
[18:37:37] <petrescu7> A: no
[18:37:43] <petrescu7> David Johnston
[18:37:51] <petrescu7> DJ: issue around convergence layer.. many problems
[18:37:58] <petrescu7> DJ: being addresses slowly (CS)
[18:38:04] <petrescu7> DJ: GPGS?
[18:38:23] <petrescu7> DJ: clarification
[18:38:30] <petrescu7> DJ: vs ieee 802.3
[18:38:32] <petrescu7> 802.2
[18:38:46] <petrescu7> .16 has eth cs
[18:39:03] <petrescu7> BA: ptp cases most analogous, mixture of l2 and l3, eth didn't have, but .16 has
[18:39:09] <petrescu7> DJ: and hopefully won't in the future
[18:39:14] <petrescu7> Soohong PArk
[18:39:22] <petrescu7> SP: DJ pointed out so far
[18:39:32] <petrescu7> SP: eee doesn't have multiple encap concern
[18:39:38] <petrescu7> SP: IPCS is just for mobility cases
[18:39:49] <petrescu7> SP: Ethernet CS is for foxed and ...
[18:40:01] --- magnus has joined
[18:40:09] <petrescu7> SP: not sure how to deal with this case from the 16 perspective thank you
[18:40:34] <petrescu7> DJ: you can't support multiple support layers, it's analogous to having in Ethernet, two Ethernet wires. The connections in .16 are independent
[18:40:53] <petrescu7> BA: document talks about... multiple prefixes and use routing to tell apart.
[18:41:25] <petrescu7> Jun Bi preparing? Ron? Ron Bonica?
[18:41:37] --- Antoin has joined
[18:41:44] --- Antoin has left
[18:42:02] <petrescu7> Ron Bonica
[18:42:16] <petrescu7> slide: Source Address Validation Architecture (SAVA)
[18:42:30] <petrescu7> slide: what does SAVA protect
[18:42:59] <petrescu7> slide: What Is The Problem
[18:43:03] <petrescu7> Paul Ferguson
[18:43:12] <petrescu7> PF
[18:43:56] <petrescu7> slide: Best Common Practice
[18:44:30] <petrescu7> slide: What Are The Constraints
[18:44:57] <petrescu7> PF: has been following
[18:45:04] <petrescu7> PF: BCP 38
[18:45:20] <petrescu7> PF: how this particular position presents itself as a better ooption than bcp 38
[18:45:42] <petrescu7> slide: What Are the Gaps Between SAVA and BCP
[18:46:05] <petrescu7> slide: What Do Solutions Look Like
[18:46:38] <petrescu7> slide: Trust
[18:46:56] <petrescu7> slide: Problems Remaining to be Solved
[18:47:05] --- dthaler has left: Replaced by new connection
[18:47:18] <petrescu7> slide: What's Next
[18:47:46] <hartmans> Wait, is there actually sufficient interest that the problem is useful to solve to propose an rg?
[18:47:49] <petrescu7> Jun Bi
[18:48:04] <petrescu7> slide: CERNET2 Experience
[18:48:58] <petrescu7> slide: CNGI-CERNET2 BAckbone
[18:49:08] <petrescu7> slide: SAVA Architecture in CERNET2
[18:50:04] <petrescu7> how can the level of interest be found?
[18:50:37] <petrescu7> slide: Mechanisms (possible SAVA solutions)
[18:51:36] <petrescu7> slide: CERNET2: prototype implemented and 7 SAVA test-beds deployed
[18:51:52] <petrescu7> slide: Test-bed in CERNET2/Tsinghua University
[18:51:56] <petrescu7> slide: feedback
[18:52:01] <petrescu7> Dave Thaler
[18:52:17] <petrescu7> DT: upstream router marking use to downstream
[18:52:28] <petrescu7> DT: what would do the downstream router do?
[18:52:35] <petrescu7> DT: what do different when it's marked?
[18:52:45] <petrescu7> RB: up to each operator to come forward to policy
[18:52:54] <petrescu7> RB: turn everything not trusted into best effort
[18:53:03] <petrescu7> DT: compare to bcp 38
[18:53:12] <petrescu7> DT: if marked then bypass?
[18:53:17] <petrescu7> RB: yes, not check it marked
[18:53:24] <petrescu7> DT: from your perspective is performance thing
[18:53:35] <petrescu7> DT: envisioning that trust marking is bianary?> Or spectrum
[18:53:46] <petrescu7> RB: probably latter (spectrum)
[18:53:49] <petrescu7> Bob Hinden
[18:53:56] <petrescu7> BH: is this really an important problem so solve?
[18:54:26] <petrescu7> BH: people who do attacks (IAB will talk on this) will take over room machines, not spoof, use real address... complexitiy good guys pay for, bad guys not
[18:54:33] <petrescu7> RB: not protect from that kind of attack
[18:54:37] <petrescu7> RB: relegate to
[18:54:54] <petrescu7> Aarea Director: raising bar matters or not? before start talk on solution
[18:54:59] <petrescu7> Kurt Erik
[18:55:10] <petrescu7> KE: real hard problem is ingress filtering, make it scale, deploy
[18:55:15] --- shigeya has joined
[18:55:17] --- Yoshifumi Atarashi has joined
[18:55:27] <petrescu7> RB: true not address problem how to get people to do ingress filtering
[18:55:34] <petrescu7> KE: they don't do because not scalable
[18:55:41] <petrescu7> Area Director (name?)
[18:55:52] <petrescu7> KE: if it was that easy more people would
[18:55:58] <petrescu7> AD: cable operators all do
[18:56:02] <petrescu7> room: no no
[18:56:09] <petrescu7> AD stands corrected on that
[18:56:14] <petrescu7> Eric Rosen
[18:56:33] <petrescu7> ER: claim of trust doesn't probably exist
[18:56:55] <petrescu7> ER: trust service provider at all? Certain trust on outstream mergers, maybe zero trust on outside versus inside
[18:57:07] <petrescu7> RB: spoof sources interesting problem
[18:57:23] <petrescu7> RB: next issue: any trust between operators? Willing to trust each other
[18:57:58] <petrescu7> ER: little to easy to defer to someone else. Real probmelem, worthwhile: detect source... whether an actual problem to be solved here? Worth?
[18:58:12] <petrescu7> ER: solve real problems, real possible benefit, not because it would be nice.
[18:58:18] <petrescu7> Danny Macpherson
[18:58:47] <petrescu7> DM: bioggest attacks do ... only about 50% of providfers implement urpf or bcp 38
[18:58:54] <petrescu7> DM: false into protection
[18:59:14] <petrescu7> DM: if people don't figure packet filters, not sure will enable any new protocol either, just adding overhead
[18:59:29] <petrescu7> DM: make these decisions... drop or forward, but not 'color' packets.
[18:59:47] <petrescu7> DM: urpf loose mode people think they are protected... false sense of protection..,. some caching can be used.
[18:59:52] <petrescu7> DM: authroitcative source
[18:59:56] --- mathis has joined
[19:00:01] <petrescu7> DM: chicken and egg problem, authroittative reporsitory
[19:00:13] <petrescu7> DM: capability of put 500.000 address in access list
[19:00:22] <petrescu7> DM: encourage communicty provide more capability
[19:00:40] <petrescu7> BA: from a workshop: a very real problem, DNSSEC coming out, reflection attacks possible
[19:00:53] <petrescu7> BA: issue bcp 38
[19:01:08] <petrescu7> BA: not poor, but you need 100% of it to really matter. but never will it be 100%
[19:01:29] <petrescu7> BA: generic issue to all security mechanisms: if not 100% then risk of taking down major parts of internet
[19:01:42] <petrescu7> BA: constraints: lot of providers had really old type of routers
[19:01:47] <petrescu7> BA: constraints you're under
[19:01:53] <petrescu7> BA: they had a harder...
[19:02:06] <petrescu7> DJ: what would this would achieve that
[19:02:10] <petrescu7> RB: not the second is?
[19:02:20] <petrescu7> RB: not familiar
[19:02:23] --- harald has joined
[19:02:33] <petrescu7> BA: question? old moldie device?
[19:02:44] <petrescu7> BA: lots of alternatives if you gonna do that stuff
[19:03:19] <petrescu7> DT: question; it's not werid to me, this being a per packet problem: whether you trust something, something that can vary packet-by-packet basis
[19:03:34] <petrescu7> DT: if you trust what the source of packet comes from, it seems you trust, or drop.
[19:03:49] <petrescu7> DT: I don't yet see the scenario where I can deliver my router packets marked or not marked
[19:03:56] <petrescu7> DT: there might be a marking proposal
[19:04:03] <petrescu7> RB: answers
[19:04:13] <petrescu7> DT: how confident is you on which router came from
[19:04:15] <petrescu7> RB: yes
[19:04:25] --- jheffner@psc.edu has joined
[19:04:32] <petrescu7> RB: assign to a packet, a function a router touched downstream
[19:04:38] <petrescu7> DT: on a point to point link it's obvious.
[19:04:48] <petrescu7> DT: but exchange link, what other trust the other guys
[19:04:57] <petrescu7> Paul Ferguson
[19:05:00] <petrescu7> PF: v6
[19:05:17] <petrescu7> PF: v6 and v4 type of not just implementation, but SAVA is looking at solving
[19:05:23] <petrescu7> PF: both v4 and v6?
[19:05:25] <petrescu7> RB: v6 only
[19:05:28] <petrescu7> room: why
[19:05:35] <petrescu7> RB: not sure problem solvable in v4
[19:05:43] <petrescu7> Mark Townsley
[19:05:48] <petrescu7> MT: do we have a problem
[19:05:55] <petrescu7> MT: two extreme oppinions
[19:05:58] <petrescu7> MT: one from Bob
[19:06:07] <petrescu7> MT: raise the bar, hackers already have it done
[19:06:18] <petrescu7> MT: then from 'Daniels?'... other approach
[19:06:21] <petrescu7> PF: both exist
[19:06:26] <petrescu7> MT: do we have a problem?
[19:06:36] <petrescu7> asking for hums
[19:06:42] <petrescu7> MT: is there a solvable problem here?
[19:06:50] <petrescu7> room: noisy angry
[19:06:54] <petrescu7> Sam Hartman
[19:07:06] --- dthaler has joined
[19:07:20] <petrescu7> SH: not clear to him whether the issue is spoofing something we'd like to solve, is connected to is the... SAVA
[19:07:27] <petrescu7> MT: is spoofing something we try to solve?
[19:07:52] <petrescu7> SH: Bob pointed suspected that implication, that report, bcp 38 wasn't a big ideal... workshop... traffic.
[19:08:04] <petrescu7> SH: workshop reported you could solve spoof traffic problem would be useful
[19:08:13] <petrescu7> MT: there is a consesnsius there's a problem
[19:08:25] <petrescu7> MT: is there something in SAVA to ask
[19:08:37] <petrescu7> BA: I do think it might be worth, apparently there is a solution
[19:08:42] <petrescu7> MT: we talk ietf, irtf?
[19:08:58] <petrescu7> MT: look at existing solutions, deploy more, or look at new protocol.
[19:09:10] <petrescu7> James Kempf JK
[19:09:30] <petrescu7> slide: SeND Follow On
[19:09:37] <petrescu7> slide: Follow On Issues for SEND
[19:10:31] <petrescu7> slide: Interoperability Issues and Test?
[19:11:03] --- jheffner@psc.edu has left
[19:11:43] <petrescu7> slide: Unresolved issues from RFC 3971
[19:12:22] <petrescu7> slide: Non-CGA Secure Addresses
[19:13:37] <petrescu7> BA: IEEE 802.1r does an effort to stds that MAC
[19:13:46] <petrescu7> BA: mentions SeND
[19:13:48] <petrescu7> JK: ah
[19:14:07] <petrescu7> BA: assumption is you have a device ceert from manufacturer
[19:14:12] <dthaler> 801.1r or 801.1ar?
[19:14:13] <petrescu7> JA: deployed?
[19:14:25] <petrescu7> r I believe not ar (what's ar?)
[19:14:57] <petrescu7> slide: Other Uses for CGAs
[19:15:18] <dthaler> 802.1ar = Secure Device Identity http://www.ieee802.org/1/pages/802.1ar.html
[19:15:24] --- magnus has left
[19:15:41] --- mikemlb has joined
[19:16:00] <dthaler> 802.1r = GARP Proprietary Attribute Registration Protocol (GPRP) http://www.ieee802.org/1/pages/802.1r.html
[19:16:08] <dthaler> so probably 802.1ar
[19:16:24] <petrescu7> JK: may be an incosnsitency
[19:17:47] <petrescu7> slide: Secure Proxy ND
[19:18:30] <petrescu7> Alan Durand
[19:18:50] <petrescu7> AD: in v6ops we have deploying ipv6 on wimax... share a prefix among basestation... look at proxy ND because no multicast
[19:18:57] <petrescu7> AD: also on docsis where maybe useful
[19:19:00] <petrescu7> Erik Nordmark
[19:19:12] <petrescu7> EN: 16ng not proxy, but relay DAD, which does work with SeND
[19:19:27] <petrescu7> JA: 16ng work is removing things they thought they need
[19:19:31] <petrescu7> Fred Templin
[19:19:41] <petrescu7> FT: proxy Rrelay and secure proxy nd not same thing
[19:19:44] <petrescu7> Sam Hartman
[19:19:54] <petrescu7> SH: proxy nd is not a stds track right?
[19:19:59] <petrescu7> JK: not any document
[19:20:02] <petrescu7> SH: one came to iesg
[19:20:14] <petrescu7> JK: there's a draft
[19:20:26] <petrescu7> en: rfc... if you do proxy (2461) then ...
[19:20:37] <petrescu7> EN: mobile ipv6 on home network says you use proxy nd
[19:20:41] <petrescu7> EN: only place I know about
[19:20:51] <petrescu7> SH: when I noticed document dont' seem to work
[19:21:06] <petrescu7> SH: if you get to a point where you decide SeND is not useful enough then...
[19:21:13] <petrescu7> JK: it is useful, people don't use
[19:21:16] <petrescu7> Vidya NArayanan
[19:21:23] <petrescu7> VN: multiple levels to this analysis
[19:21:43] <petrescu7> VN: if somenbody decides not enough usable on foreign, then why is that not enough for the home network.
[19:21:57] <petrescu7> VN: then are there any deployments whith home link deployed physical
[19:22:11] <petrescu7> JK: most people deploy MIP6 HAs the way they deploy VPN GWs.
[19:22:30] <petrescu7> slide: Proxy Neighbour Discovery Problem for MIPv6
[19:22:55] <petrescu7> slide: Comparison of Secure Proxy Neighbour Discovery Solutions for MIPv6
[19:23:54] <petrescu7> VN: one case where I can't see lot of an issue is when
[19:24:03] <petrescu7> VN: we start laying MIP6 and netlmm together
[19:24:11] <petrescu7> VN: then there is possible that there is extended link
[19:24:14] <petrescu7> extended home link
[19:24:30] <petrescu7> VN: if we do restriction 3775 that home link is virtual would it apply to a sort of mixing arch
[19:24:47] <petrescu7> JK: should be discussesd in the context of developping of netowkr mobility rptocotols
[19:24:56] <petrescu7> JA: any interested raise hands to SeND?
[19:25:10] <petrescu7> some hands were raised
[19:25:17] <petrescu7> VN: which extensions? CGA?
[19:25:26] <petrescu7> JA: who's interested in extensions to CGAs
[19:25:30] <petrescu7> JA: 10-15
[19:25:35] <petrescu7> JA: extensions to SeND?
[19:25:39] <petrescu7> JA: a few less
[19:25:46] --- magnus has joined
[19:26:52] <petrescu7> Vidya Narayanan presenting
[19:26:59] <petrescu7> slide: IP Mobility: Threat models...
[19:27:03] <petrescu7> slide: Outline
[19:27:26] <petrescu7> slide: Introduction and Goals
[19:28:19] <petrescu7> slide: Overall Mobility Architecture
[19:28:52] <petrescu7> slide: Definitions
[19:29:14] <mathis> oh I need to go into int area
[19:29:30] <petrescu7> slide: Assets
[19:30:38] <petrescu7> Dave, I checked 802.11ar 'presentations' and couldn't find 'send'. The drafts are protected.
[19:30:51] <petrescu7> slide: The Internet Threat Model - A Recap
[19:31:55] <petrescu7> slide: Routing and Byzantine Failures
[19:32:45] <petrescu7> slide: Mobility and Failure of Non-critical Nodes
[19:33:02] <petrescu7> slide: Don't Mess With Routing
[19:34:00] <petrescu7> slide: Threats to IP Mobility Provider
[19:34:35] <petrescu7> slide: Threats to IP Mobility Recipient
[19:34:58] <petrescu7> slide: Mobility Protocols Facilitate Attacks
[19:35:45] <petrescu7> slide: The Power of an Off-path Attacker
[19:36:44] <petrescu7> slide: Redirection Attacks
[19:37:23] <petrescu7> slide: Distributed DoS Attacks
[19:38:23] <petrescu7> slide: Denial of Service Attacks
[19:38:35] <petrescu7> slide: Reflection Attacks
[19:39:00] <petrescu7> slide: Security Requirements
[19:39:21] <petrescu7> slide: Channel Security
[19:39:41] <petrescu7> James Kempf
[19:39:58] <petrescu7> JK: how is this different than any other case where you need security between two IP nodes
[19:40:07] <petrescu7> VN: channel security is the basic requirement
[19:40:19] <petrescu7> VN: I PAddress Auhtorization (1/2)
[19:41:07] <petrescu7> slide: IP Address Authorization (2/2)
[19:41:41] <petrescu7> slide: Entity Authorization
[19:42:58] <petrescu7> slide: Protection Against Non-Critical Asset Compromise
[19:43:37] <petrescu7> slide: Protection for Unrelated Entities
[19:43:50] <petrescu7> slide: Takeaways
[19:44:45] <petrescu7> Suresh Krishnan
[19:45:02] <petrescu7> SK: questionable assumptions on the 'above' word.... where did this come from?
[19:45:12] <petrescu7> VN: this brings the domino effect into account
[19:45:20] <petrescu7> VN: there may be a better way of phrasing that req
[19:45:34] <petrescu7> VN: entities that are not involved into protocol get compromised, they shouldn'....
[19:45:39] <petrescu7> SK: AR is a criticial asset
[19:45:59] <petrescu7> VN: compromise of AR leads to failure of session of AR, but not of protocol itsefl
[19:46:04] <petrescu7> SK: draw a line somewhere
[19:46:21] <petrescu7> VN: if session is between MN and mobility agent and AR in the path... there are multiple ARs
[19:46:24] <petrescu7> SK: usually not
[19:46:35] <petrescu7> SK: only one AR usually
[19:46:43] <petrescu7> VN: on a given subnet yes, but mobility agent no
[19:46:55] <petrescu7> VN: say I have a mobile attempt to connec t wireles.s..
[19:47:11] <petrescu7> VN: if you used first AR as a key distirbutor
[19:47:26] <petrescu7> VN: even if that AR is functioning, the one you use,... failur of sessions elsewhere
[19:47:39] <petrescu7> JA: next steps?
[19:47:44] <petrescu7> VN: writing a document
[19:50:37] <petrescu7> Geoff Huston
[19:50:42] <petrescu7> slide: who are you?
[19:51:05] <petrescu7> slide: Addresses and the IP Architecture
[19:52:15] <petrescu7> slide: IP Addresses are:
[19:53:27] <petrescu7> slide: Challenges to the IP Address Model
[19:58:00] --- hartmans has left
[19:59:04] <petrescu7> slide: Wouldn'y be good if...
[20:00:27] <petrescu7> slide: Wouldn't it be good if...
[20:01:53] <petrescu7> slide: What do we want from "Identity"?
[20:04:31] <petrescu7> slide: Choices, Choices, Choices
[20:09:41] --- harald has left
[20:10:22] <petrescu7> slide: Identity Issues
[20:11:50] <petrescu7> slide: Identity Implementations
[20:12:42] <petrescu7> slide: Identity Types
[20:12:55] --- magnus has left
[20:13:44] <petrescu7> JA: at least we hope so
[20:14:54] <petrescu7> slide: Some Identity Suggestions
[20:15:34] <petrescu7> slide: Identity Issues
[20:16:34] <petrescu7> slide: Upper Level Issues of Identity Realms
[20:18:38] <petrescu7> slide: IPv6 and Identity
[20:20:12] <petrescu7> slide: Chinese title (not Japanese)
[20:20:49] --- jasso1 has left
[20:21:03] <petrescu7> JA: adjourned
[20:21:05] --- petrescu7 has left
[20:21:06] --- peetu has left: Logged out
[20:21:33] --- ks has left
[20:21:55] --- dudi has left
[20:21:56] --- shigeya has left: Logged out
[20:22:54] --- arifumi has left
[20:25:14] --- Yoshifumi Atarashi has left: Replaced by new connection
[20:30:10] --- mikemlb has left
[20:33:15] --- nm has left: Replaced by new connection
[20:33:15] --- nm has joined
[20:33:15] --- nm has left
[20:33:48] --- mathis has left
[20:35:54] --- arifumi has joined
[20:40:15] --- rbless has left: Disconnected
[20:45:11] --- dthaler has left
[20:45:54] --- rbless has joined
[20:55:09] --- rbless has left
[21:07:18] --- arifumi has left
[21:14:23] --- harald has joined
[21:55:59] --- harald has left
[22:05:43] --- harald has joined
[22:17:12] --- harald has left
[22:24:45] --- harald has joined
[22:26:45] --- harald has left
[22:59:53] --- harald has joined
[23:00:11] --- harald has left
[23:06:41] --- harald has joined