[Mip6-firewall] Next Steps

Wed Nov 14 11:12:08 EST 2007

As a follow up, I am suggesting Tuesday, November 27 for the conf call.

There seems to be more and more options we need to discuss as the next step. There is a new draft from Suresh/Hesham and two other drafts from Hannes/Gabor. 
Any disagreement with the currently available two drafts may be discussed if we are not able to sort them out via email.
Anything else?

There is no timeslot which would work for everyone. Possible times: 11am PST (6am Sydney, 8pm Munich, 9pm Jerusalem, 3am Singapore); 1pm PST (8am Sydney, 10pm Munich, 11pm Jerusalem, 5am Singapore); 5am PST (midnight Sydney, 2pm Munich, 3pm Jerusalem, 9pm Singapore). Any better suggestion?

If any of you is not planning to participate, let us know, that may help choosing a better time. 

feedback, please.
- gabor

________________________________

From: ext Niklas Steinleitner [mailto:steinleitner at cs.uni-goettingen.de] 
Sent: Wednesday, November 07, 2007 4:53 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: yaronf at checkpoint.com; suresh.krishnan at ericsson.com; Roberto.Baldessari at nw.neclab.eu; mip6-firewall at zeke.ecotroph.net
Subject: Re: [Mip6-firewall] Next Steps

I will arrive on Saturday evening. November 26-30 is fine with me.

Niklas

Gabor.Bajko at nokia.com schrieb: 

	So what about a phone conference sometime around November 26-30? And a f2f either Sunday evening or on Monday.

	Please propose topics for the conf call. My proposal would be to talk about solutions which enable MIP usage with the current firewalls. Hannes and myself wrote two drafts on the topic:

	http://www.ietf.org/internet-drafts/draft-bajko-mip6-rrtfw-02.txt, which describes a method to exchange addresses the peers own, and

	http://www.ietf.org/internet-drafts/draft-tschofenig-mip6-ice-01.txt, which describes how to check connectivity between address pairs of two nodes (it is based on http://ietf.org/internet-drafts/draft-ietf-mmusic-ice-19.txt).

	It would be nice if you could read these documents and post your opinions about them.

	thanks,
	-gabor

________________________________

	From: mip6-firewall-bounces at zeke.ecotroph.net [mailto:mip6-firewall-bounces at zeke.ecotroph.net] On Behalf Of ext Yaron Sheffer
	Sent: Tuesday, November 06, 2007 9:09 AM
	To: Suresh Krishnan
	Cc: Roberto Baldessari; mip6-firewall at zeke.ecotroph.net
	Subject: Re: [Mip6-firewall] Next Steps

	I'm probably coming in Sunday evening, unfortunately after the reception.

	    Yaron

	Suresh Krishnan wrote: 

		Hi Hannes,
		   I may arrive on Saturday, but I am not sure. I would prefer a phone 
		conference after the deadlines and a face2face probably before/after the 
		welcome reception.

		Thanks
		Suresh

		Hannes Tschofenig wrote:

			Hi Qiu
			Hi all,

			we should
			* update draft-krishnan-mip6-firewall
			* arrange a phone conference before the IETF meeting
			* arrange a face-to-face meeting at IETF#70.

			I wonder whether someone of you is already arriving on Saturday before 
			the meeting.
			Gabor volunteered to setup a phone conf. call (ideally after the 
			submission deadlines).

			Ciao
			Hannes

			 QIU Ying wrote:

				Hi, Firewall Folks:

				Should we update our draft "draft-krishnan-mip6-firewall-01" according to 
				the feedback getting at IETF69?

				My comments are below"

					6. Firewall Recommendations for MIPv6
					  I-D: draft-krishnan-mip6-firewall-01            15 min
					  Suresh Krishnan
					--------------------------------------
					* presentation:
					- different scenario: firewall protecting HA, MN, CN, respectively
					- recommends which kind of traffic should not be blocked by firewalls
					- Adopt as WG draft?

					* discussion
					- hesham: just to clarify, only some firewalls in enterprise networks
					block ipsec. Not in public networks
					- frank: your solution makes network less safe (let all IPsec traffic
					to HA through).
					   - Suresh: but this is the HA service, you have to let this
					   traffic through

				Frankly, in practice realm, home agents are very special nodes: 1) only few
				nodes are charged as home agents within a networks. 2) Home agent is
				normally functioned as a server or a stationary machine at least, so it is
				strong enough to protect itself (e.g. Jari mentioned access mechanisms) and
				not have to rely on the protection of firewall.

				A firewall that opens few channels for some specified robust nodes do not
				means to weaken the strength of network security.

				But in order to prevent the flood attacks, the firewall can constrain the
				throughput of these channels.

					- Alex: some operators don't want to allow RO due to security weaknessses
					   - Suresh: that's why we separated rules for RO and for non-RO

				No matter RO or non RO, the issue of IPsec packets through a firewall can
				not avoid due to home binding update.

				Any more comments?

				Regards
				Qiu Ying

				----- Original Message ----- 
				From: "Roberto Baldessari" <Roberto.Baldessari at nw.neclab.eu> <mailto:Roberto.Baldessari at nw.neclab.eu> 
				To: <nemo at ietf.org> <mailto:nemo at ietf.org> ; <mext at ietf.org> <mailto:mext at ietf.org> 
				Sent: Tuesday, November 06, 2007 5:18 PM
				Subject: [MEXT] Nemo/Mext meeting at IETF-70?

				Hi all,

				According to the IETF draft agenda, no NEMO nor MEXT WG meeting has been 
				scheduled yet. Are there plans to have one at IETF-70?

				Concerning the activity on automotive requirements for NEMO RO, we are in 
				the process to update the doc according to the feedback we got at IETF-69 
				and preparing it to include/unify requirements from both C2C-CC and ISO 
				CALM.

				Anyway, as (I guess) the contributions from CALM won't be ready in time for 
				IETF-70, I don't have anything against waiting until IETF-71 to present a 
				more complete document. Also, I hope that by then MEXT WG will be actually 
				in place.

				Best regards,

				Roberto

				================================================
				Roberto Baldessari
				Research Scientist
				NEC Laboratories, Network Division, NEC Europe Ltd.
				Kurfuerstenanlage 36, D-69115 Heidelberg
				Tel.     +49 (0)6221 4342-167
				Fax:     +49 (0)6221 4342-55
				e-mail:  roberto.baldessari at nw.neclab.eu
				web:     http://www.netlab.nec.de/

				NEC Europe Limited | Registered Office:
				NEC House, 1 Victoria Road, London W3 6BL
				Registered in England 2832014
				================================================

				_______________________________________________
				MEXT mailing list
				MEXT at ietf.org
				https://www1.ietf.org/mailman/listinfo/mext 

				------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged.  If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.--------------------------------------------------------
				_______________________________________________
				Mip6-firewall mailing list
				Mip6-firewall at zeke.ecotroph.net
				https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall

			_______________________________________________
			Mip6-firewall mailing list
			Mip6-firewall at zeke.ecotroph.net
			https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall

		_______________________________________________
		Mip6-firewall mailing list
		Mip6-firewall at zeke.ecotroph.net
		https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall

________________________________

	_______________________________________________
	Mip6-firewall mailing list
	Mip6-firewall at zeke.ecotroph.net
	https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall

-- 
Niklas Steinleitner          Tel: +49 551 3913583
Institute for Informatics    steinleitner at cs.uni-goettingen.de
University of Göttingen      http://www.tmg.informatik.uni-goettingen.de
Lotzestrasse 16-18
D-37083 Göttingen, Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071114/951993f3/attachment-0001.html 