[05:56:38] --- fdupont has joined [06:03:42] --- rjaksa has joined [06:07:44] --- behcet.sarikaya has joined [06:09:01] --- sureshk has joined [06:09:20] I am the jabber scribe [06:11:17] and the minute taker [06:11:22] --- behcet.sarikaya has left [06:11:37] Francis to present dhcp relay agents and nemo [06:11:40] --- behcet.sarikaya has joined [06:11:41] No Slides [06:12:13] --- john.zhao has joined [06:12:58] On one side we have DHCPv6 is used for address assignment [06:13:18] we are using it for prefix delegation as well [06:13:24] We have two proposals for PD [06:13:36] he thinks neither of them can get consensus [06:14:01] That is why we need a solution with relays [06:14:16] Talks about the advantages of these [06:15:09] Francis has implemented DHCP code twice [06:15:20] Relays are small and straightforward [06:16:07] Putting relays at two ends is a nice way of encapsulating dhcp traffic [06:16:38] He thinks it is a nice way of getting consensus [06:16:52] Julien points out that only one of the proposals uses DHCP [06:17:20] Francis says the other one can use a DHCP message piggybacked on a BU/BA [06:17:37] Julien does not see the point in optimizing PD [06:17:53] It happens rarely and not on critical path [06:18:21] George mentions that the good thing about this proposal is that there is no need to do any protocol work [06:18:33] he thinks that the draft is unclear but can be fixed [06:19:05] Sri wants to compare this to the Pascal/Ralph draft [06:19:59] Why not use 3315 [06:20:14] --- tk2x has joined [06:45:59] --- xiaohunhun has joined [06:46:03] --- xiaohunhun has left [06:47:04] --- juampe@jabber-hispano.org has joined [06:48:55] --- fdupont has joined [06:52:59] --- kodonog has joined [06:53:20] --- TJ has joined [06:53:25] hmmm [06:53:38] hard to join this from ichat on my mac. [06:53:49] it joined once but then died [06:54:20] --- sureshk has joined [06:54:23] is kinda unstable today [06:54:31] yup that's what i heard. [06:54:33] the jabber room was dead for 30 mins [06:54:41] I will try to post my minutes [06:54:59] maybe someone did a ddos during the PD topic... ;-) [06:57:16] i think someone should have read the draft out loud during this 10 minutes. ;-D [07:00:50] --- kodonog has left [07:06:50] Colocate the relay and client to gain simplicity Alex thinks the diff b/w this doc and the Thubert/Droms draft is the encapsulation of the DHCP packets He is not sure it can work Francis is aware of someone who uses this. Alex agrees that it is worth exploring as a solution behcet discussed this on monday at dhc, ralph mentioned that this requires standardization. behcet posted 2 drafts on this issue and he seeks comments Julien wants to know about the security Francis mentions it is just like DHCP (no security) he mentions the dhcp auth option Alex mentions that multicast and anycast are hard to secure Francis mentions you can use IPsec Ryuji wants to know how to configure the dhcp server on the relay Francis mentions there is a list of servers configured on the relay You can use an anycast scope (all servers and relays>ll scope) Francis believes it is good to put a relay or a server on the HA The main diff between the PT/RD doc is if we put the relay on the MR. Maybe we can update the PT/RD doc Fred Templin is colocating the relay and server the same in autoconf Teco Boot agrees to update the PT/RD doc and then try to get consensus Sri wants to know what happens after the tunnel disappears. How does the DHCP relay work? Will the DHCP packets get routed to HA Behcet thinks that the tunnel vanishes after the MR returns home George wants to mention that once you deregister the prefixes obtained from DHCP are gone Sri and George to discuss offlist Sri wants to couple the ventual solution to the mobility signaling Marcelo wants to know if the nemo pd draft can use the contents of this draft to fix these issues? Alex supports both the proposals. He thinks we are going too fast for the market and it is too early to choose Alex wants a list of solutions MArcelo says we are Teco thinks that if the dhcp has to disappear with the tunnel, then the dhcp pd is not an option. francis mentions the dhcp release jari confirms that we can do only one solution. if we cannot decide we should do nothing. he wants to see some direction from wg behcet agrees with jari but the authors are not here, jari tj thru ryuji why not use dynamic dns for mobility francis thinks dhcp pd should be based on dhcpv6 julien thinks pd entails state keeping in the dhcp server. there is no choice george mentions that dhcp-pd is used over lte, pmip and dsmip links Marcelo to do a consensus call dhcp vs pbu 20-1(Sri) Firewall documents Nobody has read them 10 minutes to read and comment Henrik wants to reduce timeout from 420 sec to something more reasonable Jari thinks that the document is talking about ipv6 issues as well. he wants to scope down the document Marcelo and Sri want one document Suresh disagrees Henrik agrees with suresh. It makes it clear and concise Sri thinks it can be a section Henrik wants a smaller document focussed at SOHO router vendors Jari thinks the merge/split document is not the right discussions he wants to discuss next steps marcelo wants to address jari's comments to pull out general ipv6 stuff from doc and then ask for adoption Radius MIP6 support skipped since there is nobody to present RFC3775bis Julien discussing [07:07:17] Please refer to slides [07:07:29] dhaad removal [07:07:51] jari thinks the methodology for doing this update is wrong [07:08:14] he wants to see if the functionality has been implemented and used [07:08:22] if it is not, it is fine to remove [07:09:00] gerrado thinks that we are removing something that has been outdated by other work (e.g. bootstrapping work) [07:09:36] jari thinks we need to also judge future interest [07:09:52] alex knows about 2 implementations of dhaad [07:10:39] alex thinks the scenarios for bootstrapping are different than those for dhaad [07:10:46] has diameter outdated radius [07:10:55] has ikev2 outdated ikev2 [07:11:36] gerardo clarifies that he did not mean bootstrap work was more advanced but it is more adopted and used [07:12:59] charlie wants this discussion to ml [07:13:11] sri has implementation and does not want to remove [07:13:26] george agrees with sri to keep it [07:13:41] but the security implications must be clarified [07:13:59] JMC mentiones ikev1 is obsoleted by ikev2 [07:14:04] Alex does not care [07:14:14] Jari thinks there is support to keep in the doc [07:14:41] Marcelo wants to have some diff text about the security issues [07:15:09] sri wants to leverage existing text [07:15:33] alex mentions there is already language in rfc3775 [07:15:52] JMC sent some text to ML and Alex agrees with it [07:16:14] --- TJ has left [07:17:05] slide 5 of update [07:17:21] --- dvijay has joined [07:17:33] Alex and Ryuji HAs can send BRR/Berr [07:18:06] jari thinks that binding errors can be sent by both HAs and CNs [07:18:55] jari thinks that this was the intent and the text in RFC3775 is unclear about the term CN [07:19:02] slide 6 [07:20:44] Jari and Alex need to agree about BRRs [07:22:05] Deng Hui needs clarification since he faced the problem with ha switch [07:22:16] slide 7 [07:22:38] sri agrees to switch SHOULD to MUST [07:22:58] George wants to keep the SHOULD [07:23:38] he wants the capability to decide when to send [07:24:16] sri and jari mention it is a MUST when the node wants to start using its home address [07:24:29] slide 8 [07:25:09] slide 9 [07:25:20] grab bag of issues with no text. to be discussed [07:25:54] --- chanwah.ng has joined [07:26:02] --- behcet.sarikaya has joined [07:26:10] we will accept new issues for 3 months [07:26:16] and then try to close them [07:26:50] henrik wants all the issues in the issue tracker [07:27:17] --- speermint has joined [07:28:00] --- rjaksa has joined [07:28:25] new charter items [07:28:35] binding revocation - wassim presenting [07:28:40] --- speermint has left [07:28:40] sorry sri presenting [07:28:48] since ahmad is not there [07:29:31] slide 2 [07:30:20] slide 3 [07:31:43] slide 4 [07:31:46] slide 5 [07:33:12] slide 7 [07:34:04] slide 8 [07:34:21] --- gerardo has joined [07:34:34] --- gerardo has left [07:35:33] jari thinks that the document is generally solid [07:35:43] generic notification messages [07:35:45] sri presenting [07:36:00] --- xiaohunhun has joined [07:37:15] slide 2 [07:38:05] henrik thinks the most obvious notification scenario is revocation and it is not mentioned in this doc [07:38:57] Subtype 0 should be reserved - not create some "unbounded" notification message [07:39:36] I am referring to slide 9 [07:40:33] Sri mentions that notification requires no receiver action [07:40:42] --- john.zhao has joined [07:40:45] but revocation does [07:40:56] vijay I do not see slide 9 but I will relay the question [07:41:01] and hope sri understands [07:42:04] quickly skips all slides to slide 8 [07:42:08] end of presentation [07:42:41] --- tk2x has joined [07:42:50] virtual home link configuration [07:43:30] slide 2 [07:44:57] slide 3 [07:45:56] hesham thinks anycast is no different in v6 than in v4 [07:46:09] he thinks the only difference is a reserved prefix [07:46:20] in v6 for link specific anycast [07:47:22] francis thinks that a specific prefix has not been defined [07:47:24] but can be defined [07:48:07] Ryuji rfc3775 assumes that prefix is a /64 [07:48:18] We have a specific prefix reserved for DHAAD anycast [07:51:15] RFC 2526 reserves one for Mobile IPv6 [07:51:25] it is not a prefix [07:51:31] it is an IID vijay [07:51:50] my bad [07:51:52] You rae right [07:51:58] There is no prefix reserved [07:52:01] Discussion to continue on list [07:52:12] Acee wants to know if this doc will be informational [07:52:15] sri thinks so [07:52:24] Is this assumption the virtual interface will be "always up" really valid? [07:52:35] What if the virtual interface is tied to something in the real world? [07:52:49] --- xiaohunhun has left [07:52:49] the presentation is finished tk2x [07:52:55] and the next one has started [07:53:00] maybe you can ask on the ML [07:53:02] i.e., I have a gif0 interface on my machine.. But when the tunnel is gone, or the physical interface down, the virtual interface isn't there [07:53:06] George presenting DSMIPv6 [07:53:08] Yeah I know I am just posing the question [07:53:35] slide 3 [07:53:41] slide 4 [07:54:09] tk2x it is just a implementation/deployment issue. [07:54:22] they are talking about a virtual interface similar to loopback [07:54:25] that never goes down [07:55:06] The slides are exactly the same as Karen presented at the last IETF :) [07:55:48] :-) [07:55:55] suresh: right.. i am just wondering, since i haven't implemented a virtual home link before. [07:56:47] Domagoj wants to know about the usage scenarios [07:58:00] v4 HoA as the CoA for the v6 HoA [07:58:23] jari talking about the AltCoA check draft [07:58:45] slide 3 [07:59:20] slide 2 [07:59:28] slide 2 [08:00:55] slide 4 [08:01:20] Yikes [08:01:31] Binding a v4 HoA with v6 HoA? [08:01:48] you are about 10 minutes late [08:01:53] take it up on ML [08:02:02] with Domagoj and George [08:02:22] Hesham is neutral to this change [08:02:52] it is good because this can be enabled and disabled on the receiver [08:02:59] based on the info in the BU [08:04:10] Text changes needed to FMIP and have been made [08:04:26] --- behcet.sarikaya has left [08:04:47] FMIP? Or is it DSMIP? [08:04:57] jari mentions fmip has a more specific rule for alt-coa handling [08:05:00] FMIP [08:05:17] Jari has started his presentation, I guess [08:05:23] yep [08:05:53] ryuji mentions that MCOA does not use Alt-CoA [08:06:21] so there is no conflict b/w this proposal and monami6 work [08:07:12] but jari thinks the problem still exists [08:07:29] do we trust the node to just check one of the addresses in the packet? [08:07:36] he has now thought much about this yet [08:07:49] sri wants to know if there is a configuration knob [08:08:09] Jari mentions that it is tuned on by default but can be turned off [08:09:05] Ryuji wants to mention whether the src address or alt-coa will be used by the HA [08:09:51] Christian wants some kind of negotiation between the HA and the MN to see if it is turned on [08:09:57] Jari does not like to have negotiation [08:10:39] George mentions there is no point negotiating with a potential attacker [08:11:33] Alex wants more granularity (per HoA basis) [08:12:33] jari wants to take some time to see if we can accomodate the mcoa stuff in this doc [08:12:39] within say 3 months [08:12:52] George presenting residual threats [08:12:55] slide 2 [08:12:59] --- behcet.sarikaya has joined [08:13:54] slide 3 [08:14:15] george solicits more inputs on threats [08:15:12] francis thinks attacks are very easy if we are attached to multiple links (at least one of the valid CoAs is used) [08:15:28] slide 4 [08:17:14] Julien wants to know how CGA helps [08:17:44] It prevents flooding a specific address but not flooding a link [08:17:55] slide 6 [08:18:46] we want to identify what threats are still left when ingress filtering is turned on [08:19:09] JMC wants to know if the work takes into account the work done in sava/savi [08:19:24] Marcelo wants to document the threats first [08:19:33] and then decide what to do with them later [08:20:05] the scope of the work is threats that are SPECIFIC to mipv6 [08:21:09] Hesham wants to know about ingress filtering stats [08:21:38] George mentions that we can create optional mechanisms that only paranoid people turn on [08:22:01] Christian Vogt mentions 25% of internet addresses can be spoofed [08:22:33] savi wg is more limited only source address validation on local link [08:23:47] Francis mentions that there are attacks that do not use source addresses and they cannot be covered by ingress filtering [08:24:12] Marcelo wants to cover all cases [08:24:23] not just CoA address issues [08:24:48] Jari wants to focues the document without making huge claims [08:26:19] Jari mentions that the relationship between the HA and Mn is traceable [08:26:53] Anonymous HAs would be a good idea but they do not exist [08:27:05] --- behcet.sarikaya has left [08:27:20] George mentions that the device can be traced, but not the user [08:27:31] e.g. SIM [08:27:43] Jari mentions that a SIM can be traced to a user [08:28:21] George says not in Europe [08:28:22] If a SIM is lost, it is reported by the user and marked as stolen is just a few hours [08:28:38] you can buy a prepaid sim without registering [08:29:03] Most countries allows require some sort of identification before buying a prepaid SIM [08:29:08] JMC says that is not true in France [08:29:11] I meant laws [08:29:17] George says we will not do this for France [08:29:21] (laughter) [08:29:58] Jari mentions that this work might have an effect on MCOA [08:30:13] and hence we need to analyze the effects [08:31:06] --- juampe@jabber-hispano.org has left [08:31:12] --- jpc has joined [08:31:19] simultaneous mobility presentation [08:31:57] alide 2 [08:32:58] slide 3 [08:33:08] If an operator does not know who the SIM belongs to, there is a bigger issue for the operator than just DS-MIPv6 attacks [08:33:13] Just an obversation [08:33:23] slide 5 [08:33:28] slide 4 [08:33:41] slide 5 [08:34:05] --- chanwah.ng has left [08:34:19] alide 6 [08:34:24] --- dvijay has left [08:37:03] slide 8 [08:37:10] slide 9 [08:37:26] --- sureshk has left [08:37:55] --- sureshk has joined [08:38:13] Hesham wants to know ehether we are documenting or trying to solve [08:39:40] --- fdupont has left: Computer went to sleep [08:39:44] francis mentions that rh + hao is worse than tunneling and is a security nightmare [08:40:34] --- john.zhao has left [08:43:36] --- rjaksa has left [08:48:21] --- sureshk has left [09:21:01] --- jpc has left [10:10:38] --- sureshk has joined [10:11:54] --- sureshk has left [10:27:14] --- fdupont has joined [10:43:43] --- fdupont has left [12:38:34] --- tk2x has left