OK. A dumber but more practical question: Do you have any idea how we can get microphones?
The projector is indeed here, but the microphones seem to be missing. Keeping the audio stream running all night doesn't help if the mikes are gone... On Nov 16, 2011, at 7:13 PM, Stephen Hanna wrote: > I think we will benefit greatly if we focus tonight's > meeting mainly on discussion of and perhaps agreement > on the PROBLEM TO BE SOLVED. > > Comparison and analysis of proposed solutions should > wait until we have agreed on the problem statement > and the requirements derived from that. And, as we've > just seen, it's very hard to have a clear discussion > of different alternative proposals without having > those proposals described in detail as Internet-Drafts. > > The goal of the 7 minute presentations of solutions > tonight (as I understand it) is simply to show that > there are some interesting solutions out there, not > to promote comparisons of them. I already regret > the decision to include those solutions on the agenda > since we've now spent lots of time insulting each > others' approaches without actually understanding them. > > Please let's skip more shouting matches about solutions > tonight. We don't have enough facts on the table. > Instead, let's focus on discussing which problem > we should be trying to solve. > > Thanks, > > Steve > >> -----Original Message----- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Frederic Detienne >> Sent: Wednesday, November 16, 2011 4:24 AM >> To: Yoav Nir >> Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger >> Subject: Re: [IPsec] P2P VPN - Side Meeting >> >> >> You are mixing everything up. It is too much work to correct you over >> email. I will try to help you at the meeting. >> >> regards, >> >> fred >> >> On 16 Nov 2011, at 15:35, Yoav Nir wrote: >> >>> OK. >>> >>> Routing protocols are not security protocols. That's fine. Neither is >> HTTP. >>> >>> BGPSEC and SIDR implement a layer of security on top of BGP to >> overcome this issue, and that may be used in the Internet. >>> >>> OSPF and NHRP are designed to be used in closed environments >> (corporate networks), where everyone is assumed to be "playing nice", >> so there has never been as much requirement for a security layer, and >> in fact there is no security layer to NHRP. >>> >>> When you extend NHRP to an overlay network over the Internet, as you >> do with GRE, you are still fine as long as everybody "plays nice". With >> the obvious example of a corporate network with tunnels to the branches >> in New York, London, Paris, and Shang-hai you're still fine, because >> all the gateways are configured by the same person or organization, or >> at least they are part of the same hierarchy, although by this point >> you may need to be worried about misconfiguration. >>> >>> With a multiple-administrative-domain use case, all bets are off. >> What would prevent a gateway anywhere from claiming responsibility for >> the addresses of the facebook.com server? That would cause several bad >> things: >>> - that gateway gets access to all facebook traffic in the entire >> overlay network >>> - all the gateways have to work extra hard encrypting facebook >> content for no reason at all. >>> >>> This is a real problem regardless of whether we use IPsec tunnels or >> GRE tunnels. Neither IKE nor NHRP has a secure routing layer. Whichever >> solution we pick (as a working group) we will still need to develop a >> security layer, which may or may not be based on what the BGP people >> are doing. >>> >>> This is especially important for cross-domain use cases, but would be >> very helpful for same-domain as well. >>> >>> Yoav >>> >>> On Nov 16, 2011, at 3:11 PM, Frederic Detienne wrote: >>> >>>> >>>> Security is a matter of architecture and end-to-end design. Several >> mechanisms are used to achieve an efficient balance with complexity. >> Features and security protocols are only building blocks. >>>> >>>> IPsec and IKE are not the only features that protect a network and >> routing as a security policy really is not a problem until shown >> otherwise. >>>> >>>> Again, I urge you to be specific because there is nothing tangible >> in your claims. I understand what you mean but if you rationalized it, >> you would see your intuition fools you. >>>> >>>> >>>> On 16 Nov 2011, at 14:17, Yoav Nir wrote: >>>> >>>>> >>>>> On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: >>>>> >>>>>> Yoav Nir writes: >>>>>>>> So you still didn't explain what GRE does better than modern >> IPsec >>>>>>>> tunneling? >>>>>>> >>>>>>> I think GRE (or any tunnel that is not IPsec - like L2TP) allows >>>>>>> them to avoid having to deal with RFC 4301 stuff like SPD. The >> only >>>>>>> selector they need is for the GRE tunnel (protocol 43?) or the >> L2TP >>>>>>> tunnel (UDP 1701). >>>>>> >>>>>> I.e. bypass the security mechanishms provided the security >> protocol. >>>>> >>>>> Yes! >>>>> >>>>>>> That means that your security policy is effectively determined by >>>>>>> the routing protocol. >>>>>> >>>>>> I.e. move the security from the security protocol to something >> else >>>>>> which is not a security protocol. Is this really something we want >> to >>>>>> do? >>>>> >>>>> Define "we" >>>>> >>>>>> Who is going to make sure the end result is secure? >>>>> >>>>> The customer >>>>> >>>>> >>>> >>>> >>>> Scanned by Check Point Total Security Gateway. >>> >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
