Envelope-to: shim6-data@psg.com Delivery-date: Mon, 29 Jan 2007 09:07:26 +0000 Message-ID: <45BDB8FE.1030508@zurich.ibm.com> Date: Mon, 29 Jan 2007 10:06:06 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Henderson, Thomas R" CC: Geoff Huston , shim6-wg , kurtis@kurtis.pp.se Subject: Re: State of play with Shim6 documents Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >> Sent: Saturday, January 27, 2007 12:32 PM >> To: Henderson, Thomas R >> Cc: Geoff Huston; shim6-wg; kurtis@kurtis.pp.se >> Subject: Re: State of play with Shim6 documents >> >> On 2007-01-24 19:06, Henderson, Thomas R wrote: >>>> -----Original Message----- >> ... >>>> * TCP Checksum Failure >>>> >>>> Its not clear what the WG want to do on this. >> Suggestions? >>> I would vote to align the checksum with the locators, under the >>> assumption that defining an alternate probing mechanism to discover >>> these problems is more cumbersome. If you care strongly >> enough about >>> using the transport checksum to detect incorrect address >> rewriting in >>> certain error scenarios, that may argue for putting better error >>> detection in the shim proper, but I'm not sure it is a high enough >>> probability event. >> I have the opposite view. I think we should keep rock solid >> on the notion that shim6 preserves the end to end model as far >> as upper layers are concerned. Fixing the TCP checksum twice, >> on the way in and out of the shim, would be an ugly hack on >> that model, and also the first step towards inserting all >> sorts of ALG functionality in the shim to compensate for >> misbehaving middleboxes. >> >> Before taking any other decision, I'd want to see firm >> observational evidence that there is a real problem. TCP >> checksums are no business of middleboxes, except for the >> TCP relay case which would probably need to be shim6-aware. >> > > I agree that it would be best to make decision based on operational > experience, but I am suspicious about the future for IPv6 because there > is no IP checksum, so it might encourage routers or middleboxes to > provide transport checksum validation as a feature. > > But perhaps it would be prudent to devise an extension only if > shim6-awareness doesn't materialize in practice, and keep it cleaner for > now. I like that approach. I hope we have some spare bits that would allow us to signal that TCP checksum recomputation is in use. Brian Envelope-to: shim6-data@psg.com Delivery-date: Mon, 29 Jan 2007 06:24:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State of play with Shim6 documents Date: Sun, 28 Jan 2007 22:21:34 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FBD4@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: State of play with Shim6 documents Thread-Index: AcdCUiwKgrkKDj9VSjikkXcdjhuUaQBGUmtg From: "Henderson, Thomas R" To: "Brian E Carpenter" Cc: "Geoff Huston" , "shim6-wg" , =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Saturday, January 27, 2007 12:32 PM > To: Henderson, Thomas R > Cc: Geoff Huston; shim6-wg; kurtis@kurtis.pp.se > Subject: Re: State of play with Shim6 documents >=20 > On 2007-01-24 19:06, Henderson, Thomas R wrote: > >> -----Original Message----- >=20 > ... > >> > >> * TCP Checksum Failure > >> > >> Its not clear what the WG want to do on this.=20 > Suggestions? > >> > >=20 > > I would vote to align the checksum with the locators, under the > > assumption that defining an alternate probing mechanism to discover > > these problems is more cumbersome. If you care strongly=20 > enough about > > using the transport checksum to detect incorrect address=20 > rewriting in > > certain error scenarios, that may argue for putting better error > > detection in the shim proper, but I'm not sure it is a high enough > > probability event. >=20 > I have the opposite view. I think we should keep rock solid > on the notion that shim6 preserves the end to end model as far > as upper layers are concerned. Fixing the TCP checksum twice, > on the way in and out of the shim, would be an ugly hack on > that model, and also the first step towards inserting all > sorts of ALG functionality in the shim to compensate for > misbehaving middleboxes. >=20 > Before taking any other decision, I'd want to see firm > observational evidence that there is a real problem. TCP > checksums are no business of middleboxes, except for the > TCP relay case which would probably need to be shim6-aware. >=20 I agree that it would be best to make decision based on operational experience, but I am suspicious about the future for IPv6 because there is no IP checksum, so it might encourage routers or middleboxes to provide transport checksum validation as a feature. But perhaps it would be prudent to devise an extension only if shim6-awareness doesn't materialize in practice, and keep it cleaner for now. Tom Envelope-to: shim6-data@psg.com Delivery-date: Sat, 27 Jan 2007 20:33:44 +0000 Message-ID: <45BBB6AE.7010701@zurich.ibm.com> Date: Sat, 27 Jan 2007 21:31:42 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Henderson, Thomas R" CC: Geoff Huston , shim6-wg , kurtis@kurtis.pp.se Subject: Re: State of play with Shim6 documents Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2007-01-24 19:06, Henderson, Thomas R wrote: >> -----Original Message----- ... >> >> * TCP Checksum Failure >> >> Its not clear what the WG want to do on this. Suggestions? >> > > I would vote to align the checksum with the locators, under the > assumption that defining an alternate probing mechanism to discover > these problems is more cumbersome. If you care strongly enough about > using the transport checksum to detect incorrect address rewriting in > certain error scenarios, that may argue for putting better error > detection in the shim proper, but I'm not sure it is a high enough > probability event. I have the opposite view. I think we should keep rock solid on the notion that shim6 preserves the end to end model as far as upper layers are concerned. Fixing the TCP checksum twice, on the way in and out of the shim, would be an ugly hack on that model, and also the first step towards inserting all sorts of ALG functionality in the shim to compensate for misbehaving middleboxes. Before taking any other decision, I'd want to see firm observational evidence that there is a real problem. TCP checksums are no business of middleboxes, except for the TCP relay case which would probably need to be shim6-aware. Brian Envelope-to: shim6-data@psg.com Delivery-date: Fri, 26 Jan 2007 12:57:03 +0000 Message-ID: <45B9F9B6.80807@info.ucl.ac.be> Date: Fri, 26 Jan 2007 13:53:10 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: jari.arkko@ericsson.com, iljitsch@muada.com CC: shim6@psg.com Subject: About draft-ietf-shim6-failure-detection-07 {2} Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, I have another question regarding the failure detection draft. This is about the end of an exploration. I think it is useful to have a notion of - when an exploration process begins. - when an exploration process terminates. * Motivation : - An implementation might want to have a specific thread/process for each exploration. It is useful to know when the exploration thread may be terminated. - We need to store information about each probe sent/received (because reports are included in the probes). It is useful to know when the memory used by this information can be released. This would ensure that only information relative to the current exploration is stored in memory. Also, a context in operational state would need less space than a context in course of exploration, which is more scalable if lots of contexts are present. * The problem : While it is rather evident when we must trigger an exploration (send timer expiry or incoming probe exploring), we are not so certain about the end of an exploration. More precisely *one of the peers* is not certain, while the other is. Here is an example situation with the currently defined scheme for the end of an exploration : Peer A Peer B | | State: State: Inbound_OK Exploring | | | Probe Inbound OK | |-------------------------------------------->| | State: | Operational | Probe Operational | | /---------------------------------| path working, but probe lost (because of | | congestion for example) | Probe Inbound OK | |-------------------------------------------->| | | | Probe Operational | |<--------------------------------------------| | | Now B can forget its received/sent probe reports, State : | because A is in state operational, but B has no way to know it. Operational As illustrated in this scenario, when A receives a probe Operational, it knows for sure that B is operational, and so that the exploration process is terminated. But B won't receive such a probe. B enters into the Operational state when he receives a Probe Inbound OK. This means that he knows the conversation will work from now, but this doesn't mean, however, that A won't ever ask B to send its list of sent/recvd probe reports, as is the case in the above scenario (because of the first probe operational being lost). * One possible (and simple :-) ) solution : Because the only problem is for B to know for sure that A is operational. Just let it know this fact by sending another Probe Operational. Of course, with such a rule, we could end up with A and B infinitely sending Probes Operational. This can be simply solved by having something different in the last Probe Operational, such as a flag. This can also be solved by sending no probe report (psent=0 and precevd=0). This may seem contradictory with my previous mail, but it isn't : we are here in the special case where A *knows* that B is in operational state, so he doesn't need anymore to have any probe information, his only need is now to be sure that A is also in operational state. In fact, the only thing that B will do when receiving the last probe is check whether this is an operational probe or an Inbound OK probe : - in the first case : stop the exploration process gracefully - in the last case : The last probe operational from B has been lost, send another one. This results in the following (very similar, but much simpler/efficient from an implementation point of view, IMHO) scenario : Peer A Peer B | | State: State: Inbound_OK Exploring | | | Probe Inbound OK | |-------------------------------------------->| | State: | Operational | Probe Operational | | /---------------------------------| path working, but probe lost (because of | | congestion for example) | Probe Inbound OK | |-------------------------------------------->| | | | Probe Operational | |<--------------------------------------------| | | State : | Operational | | | | Probe Operational|final | |-------------------------------------------->| | | Now B can forget its received/sent probe reports, In fact, the final flag is not necessary, because there is no ambiguity, here would be the difference in the state machine : event : Reception of the probe message State Operational if in state Operational : just update timers (see draft) -> *end of exploration* if in state Inbound_OK : goto Operational, update timers AND send a probe operational if in state Exploring : goto Operational, update timers AND send a probe operational (mmm, in fact i guess this case should not occur, unless one of the peers is buggy, but this answer to this little probable event seems OK). What is your opinion ? Thanks for any comments, Sébastien. -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium Envelope-to: shim6-data@psg.com Delivery-date: Fri, 26 Jan 2007 09:25:08 +0000 From: "Taewan You" To: "'Matthijs Mekking'" Cc: , Subject: RE: shim6 interoperability / traffic analyzer Date: Fri, 26 Jan 2007 18:23:26 +0900 Message-ID: <004d01c7412b$a23db260$14110b0a@wannynb> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcdAflwvRJ8XwyTNSXOTntn/Ph+XMwAowbEg Matthijs Mekking, Past 67th IETF, some peoples, who interest implementing shim6 (Ericsson, Boeing, ETRI, and SNU), discussed in collaboration with each other, included interop. test. As a result, we had set up the email list, and wiki by Marcelo. However, so far the cooperation is the situation, which it barely starts. So currently you can not get some information from the ML or wiki about shim6 implementing work. But first, anyone who wants to interest the shim6 implementing work can rise up a thread to help or interop. test by using ML :-), then we will derive concretely action items to collaborate it. And if your information of a shim6 code also would be announced to all with much circumstance, it will in pretty handy in our implementing work. Regards, Taewan You ETRI, Korea. p.s this is the ML for implementation issues "To subscribe just send an email to: implementation-subscribe@shim6.org" > -----Original Message----- > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On Behalf Of > Matthijs Mekking > Sent: Thursday, January 25, 2007 9:36 PM > To: shim6@psg.com > Subject: shim6 interoperability / traffic analyzer > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > For my research at NLnetLabs, I'm currently working at the Wireshark > traffic analyzer that can read SHIM6. Additionally, I want to carry out > an interoperability test on the early versions of SHIM6 implementations. > I only could find the implementation of Sebastien (of the UCL, many > thanks for that), and I would like to play with an implementation from a > different code base. Is anybody interested in having their > implementation (even if it is an early version) to undertake an > interoperability test? I will present my results to this list. > > Regards, > > Matthijs Mekking > matthijs@NLnetLabs.nl > NLnetLabs/Radboud University > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFuKQtNiaStnTWEtYRAsQ+AJ936JHM7J9bzM+evKW7FUPt5lD0CQCguX8i > vVsEl907UY9mjRULAKQAiAw= > =eY4M > -----END PGP SIGNATURE----- Envelope-to: shim6-data@psg.com Delivery-date: Thu, 25 Jan 2007 12:37:01 +0000 Message-ID: <45B8A42D.6070804@NLnetLabs.nl> Date: Thu, 25 Jan 2007 13:35:57 +0100 From: Matthijs Mekking User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: shim6@psg.com Subject: shim6 interoperability / traffic analyzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, For my research at NLnetLabs, I'm currently working at the Wireshark traffic analyzer that can read SHIM6. Additionally, I want to carry out an interoperability test on the early versions of SHIM6 implementations. I only could find the implementation of Sebastien (of the UCL, many thanks for that), and I would like to play with an implementation from a different code base. Is anybody interested in having their implementation (even if it is an early version) to undertake an interoperability test? I will present my results to this list. Regards, Matthijs Mekking matthijs@NLnetLabs.nl NLnetLabs/Radboud University -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFuKQtNiaStnTWEtYRAsQ+AJ936JHM7J9bzM+evKW7FUPt5lD0CQCguX8i vVsEl907UY9mjRULAKQAiAw= =eY4M -----END PGP SIGNATURE----- Envelope-to: shim6-data@psg.com Delivery-date: Thu, 25 Jan 2007 11:18:19 +0000 Message-ID: <45B8915A.5080800@info.ucl.ac.be> Date: Thu, 25 Jan 2007 12:15:38 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: jari.arkko@ericsson.com, iljitsch@muada.com CC: shim6@psg.com Subject: About draft-ietf-shim6-failure-detection-07 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, while implementing the failure detection draft version 7 (new release available soon at http://gforge.info.ucl.ac.be/projects/shim6/), I have found some things I would like to ask precisions about : section 3.1 : available addresses ---------------------------------------------------- -- Where IPv6 link-local addresses are used, their use needs to be unambiguous as follows. At most one link-local address may be used per node within the same connection between two peers. -- Why ? What is the problem in dealing with multiple link-local addresses ? In fact, I think the problem is not in dealing with multiple link-local addresses, but rather in making sure we use a link-local address over the right link. * Using the peer's link-local address (announced during shim6 intialization in the peer locator set) : The problem is that we have no way to know if the peer is in the same subnetwork as us. Moreover, if we have multiple interfaces, which is the one corresponding to the given link-local address ? Because of this, I think it is not correct to send the link-local addresses as part of the locator list during shim6 initialization without a proper mechanism, but I also guess it is not worth designing such a mechanism, given the limited interest in doing that. * Using the local link-local address as source for exploration : If we use our link-local address as source, we know over which link to use it, but this is not really useful if we don't know if our peer is inside our subnetwork. * In summary, it appears to me that link-local addresses are not really suitable for use with shim6/reap. Am I missing something ? State machine (table 4) -------------------------------------- -- Upon a timeout on the Send timer, the node enters the Exploring state, sends a Probe, and stops the Keepalive timer if it was running. -- Why to stop the Keepalive timer ? Isn't it always stopped when the send timer is running ? (so necessarily also if it does a timeout). Incoming probe Inbound OK ---------------------------------------------- As specified in the draft, the reception of a probe Inbound OK triggers a come back to the operational state. But a come back to the operational state implies that a pair of working locators are given to the shim, for use as current locator pair. AFAIK, this locator pair must be chosen in the list of probes received : each received probe report contains a working locator pair, which may be chosen as the new current locator pair. Now, the problem is that it is possible to receive a probe Inbound OK without any probe reception report inside. For example, if the peer receives an incoming packet while in state exploring, it will send an Inbound OK probe without any source reception report. In this case the receiver of that probe is only able to know that *there is* a working locator pair, but it cannot know which is that locator pair. In fact I guess we have two solutions to solve this : - Let the draft as is : When we receive a probe Inbound OK without any received probe report (Precvd=0), we conclude that a payload packet or a keepalive has been received by the peer, which means that we can come back to the operational state without changing the current locators. (Because payload packets and keepalives are sent with current locators). - Find some way to report the reception of data packets/keepalives : In the case of probes having been received, this would allow to tell the peer that also the current locator pair is working. What do you think ? Sébastien. -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium Envelope-to: shim6-data@psg.com Delivery-date: Thu, 25 Jan 2007 11:09:20 +0000 Message-ID: <45B88EFE.7020205@info.ucl.ac.be> Date: Thu, 25 Jan 2007 12:05:34 +0100 From: =?UTF-8?B?U8OpYmFzdGllbiBCYXJyw6k=?= User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: shim6@psg.com CC: "Henderson, Thomas R" Subject: Re: State of play with Shim6 documents Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Henderson, Thomas R wrote: > from the current draft: > >> The shim6 control messages use the same extension >> header formats so that a single "protocol number" needs to be allowed >> through firewalls in order for shim6 to function across the firewall. >> > > Besides the fragmentation issue, the way it is defined now, it seems > burdensome to implementations that want to implement the shim6 control > plane as a user-space daemon (as opposed to defining a separate protocol > number for shim6 control messages). My reading of IPv6 raw sockets > semantics suggests that they cannot be used. > > from RFC 3542: > "With IPv6 raw sockets will be > used for ICMPv6 and to read and write IPv6 datagrams containing a > Next Header field that the kernel does not process." > > This is not the case for shim6 since the kernel does process the payload > extension header in the data plane. > > Under current definition, how should a user-space shim6 implementation > use IPv6 sockets API to get only the control messages? If there isn't > an easy way, should we consider to separate the protocol numbers? > In the Linux Kernel, the packets are first delivered to the raw sockets, then processed by the kernel, if some protocol is implemented to handle this. This implies that if we want to have a user space raw socket that receives only the shim6 control messages, we need to have some shim6 specific code inside the raw delivery kernel function, which is of course possible, but probably not the cleanest way to do things. So I think I agree with Thomas : It would be helpful to have a separate protocol number for control and payload messages. SĂ©bastien. > Tom > > > -- SĂ©bastien BarrĂ© Researcher, CSE department, UCLouvain, Belgium Envelope-to: shim6-data@psg.com Delivery-date: Wed, 24 Jan 2007 18:10:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State of play with Shim6 documents Date: Wed, 24 Jan 2007 10:06:27 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FBB5@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: State of play with Shim6 documents Thread-Index: Acc+fHn//8i9G1a+TuGIQiP2eeTfgwBVdElw From: "Henderson, Thomas R" To: "Geoff Huston" , "shim6-wg" Cc: > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net]=20 > Sent: Monday, January 22, 2007 3:21 PM > To: shim6-wg > Cc: kurtis@kurtis.pp.se > Subject: Re: State of play with Shim6 documents >=20 > It seems that asking these questions has stopped all further=20 > discussion on this topic, which is a pity, as it would be good to=20 > resolve these matters in the next week or so if possible. >=20 > The three topics that I see from the mailing list as being unresolved=20 > at this stage are: >=20 > * explicit shim6 error message (the lack thereof) >=20 > Its not clear what the WG want to do on this. Suggestions? I think it would be useful to define a mechanism for this, even if we do not yet have the implementation experience to decide on all the types of errors that should/should not be reported. Other control protocols such as IKE (section 2.21 of RFC 4306) have defined such messages, although whether a host generates them is a matter of security policy. In HIP, we cloned the IKE Notify parameter and defined a number of error cases that could occur during context establishment. Does this WG want to adopt something similar? Or just leave it for further study? (see the current HIP base draft, sections 4.3 and 5.2.16 (NOTIFY parameter)) >=20 >=20 > * TCP Checksum Failure >=20 > Its not clear what the WG want to do on this. Suggestions? >=20 I would vote to align the checksum with the locators, under the assumption that defining an alternate probing mechanism to discover these problems is more cumbersome. If you care strongly enough about using the transport checksum to detect incorrect address rewriting in certain error scenarios, that may argue for putting better error detection in the shim proper, but I'm not sure it is a high enough probability event. > * Control Message length >=20 > Text proposed=20 > (http://ops.ietf.org/lists/shim6/msg01780.html) > Are we in agreement with this suggestion? My first thought was "why not just use regular IPv6 fragmentation in the control plane, perhaps with IPV6_USE_MIN_MTU socket option?" but then I realized that the whole protocol is defined in terms of IPv6 destination headers below the fragmentation layer. =20 from the current draft: > The shim6 control messages use the same extension > header formats so that a single "protocol number" needs to be allowed > through firewalls in order for shim6 to function across the firewall. Besides the fragmentation issue, the way it is defined now, it seems burdensome to implementations that want to implement the shim6 control plane as a user-space daemon (as opposed to defining a separate protocol number for shim6 control messages). My reading of IPv6 raw sockets semantics suggests that they cannot be used. from RFC 3542: "With IPv6 raw sockets will be used for ICMPv6 and to read and write IPv6 datagrams containing a Next Header field that the kernel does not process." This is not the case for shim6 since the kernel does process the payload extension header in the data plane. Under current definition, how should a user-space shim6 implementation use IPv6 sockets API to get only the control messages? If there isn't an easy way, should we consider to separate the protocol numbers? =20 Tom Envelope-to: shim6-data@psg.com Delivery-date: Mon, 22 Jan 2007 23:22:57 +0000 Message-Id: <7.0.0.16.2.20070123101818.013d03a0@apnic.net> Date: Tue, 23 Jan 2007 10:20:43 +1100 To: "shim6-wg" From: Geoff Huston Subject: Re: State of play with Shim6 documents Cc: kurtis@kurtis.pp.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed It seems that asking these questions has stopped all further discussion on this topic, which is a pity, as it would be good to resolve these matters in the next week or so if possible. The three topics that I see from the mailing list as being unresolved at this stage are: * explicit shim6 error message (the lack thereof) Its not clear what the WG want to do on this. Suggestions? * TCP Checksum Failure Its not clear what the WG want to do on this. Suggestions? * Control Message length Text proposed (http://ops.ietf.org/lists/shim6/msg01780.html) Are we in agreement with this suggestion? thanks, Geoff & Kurtis Envelope-to: shim6-data@psg.com Delivery-date: Sun, 14 Jan 2007 23:05:36 +0000 Message-Id: <7.0.0.16.2.20070115070122.042beea8@apnic.net> Date: Mon, 15 Jan 2007 10:03:14 +1100 To: "shim6-wg" From: Geoff Huston Subject: State of play with Shim6 documents Cc: kurtis@kurtis.pp.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Working from the minutes of the SHIM6 WG meeting in November, and looking at the mailing list traffic since then it appears that we are about as close to submitting the HBA and Failure Detection shim6 documents to the IESG as we'll ever be, but that the Protocol specification document requires a little more discussion on a number of topics (noted below) and definitely another rev of the draft. Here's the state, as I understand it, relative to the comments raised in the Last Call and in the IETF 67the Working Group meeting 1. HBA (draft-ietf-shim6-hba-02.txt ) -- IPR issues - we appear to have reached a level of consensus with acceptance of this document in the light of the Ericsson and Microsoft IPR statements -- IANA considerations - no further issues -- Security Considerations - no further issues 2. Shim6 Protocol (draft-ietf-shim6-proto-07.txt) -- IPSEC - text added to the draft as noted in the WG meeting -- Provide SHIM 6 security based on IPSec SAs - no further action -- ULID Security Mechanism - no further issues -- DOS attacks on the context tag set - no consensus for further change -- Context Forking - no further issues -- CGA Key Length - text added to the draft as noted in the WG meeting -- Broken Flag - no further issues 3. Failure Detection (draft-ietf-shim6-failure-detection-07.txt) -- Behaviour Section - text added per comments Since then we've had a review of proto-7 by Iljitsch van Beijnum (11 December http://ops.ietf.org/lists/shim6/msg01742.html), as well as a number of other suggestions regarding thos document The major issues raised have been were: * context tag This review revisited the topic of inclusion of the context tag in the shim6 header. Followup postings to this were at ( http://ops.ietf.org/lists/shim6/msg01772.html, and http://ops.ietf.org/lists/shim6/msg01777.html) As far as I can tell there is no apparent WG consensus to alter the existing text at this point in time, * congestion control It also noted issues regarding TCP congestion control. A TCPM approach (http://ops.ietf.org/lists/shim6/msg01788.html) is described in the document http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt There appears to agreement to reference this draft in the proto document in order to address this issue. * explicit shim6 error message (the lack thereof) The review proposed a shim6 error message (http://ops.ietf.org/lists/shim6/msg01769.html) One posting in support of this (http://ops.ietf.org/lists/shim6/msg01775.html) **** Its not clear what the WG want to do on this. Suggestions? **** * TCP Checksum Failure The review noted that any intermediary system that performed a TCP checkum would fail. Proposal to add a middlebox consideration section to point out the problem and an idea to use some form of probe mechanism to detect paths with this problem Alternative proposal for the SHIM to alter the TCP and UDP checksums to match the selected locators on outgoing and match the ULIDs on incoming. **** Its not clear what the WG want to do on this. Suggestions? **** * Control Message length Text proposed (http://ops.ietf.org/lists/shim6/msg01780.html) Are we in agreement with this suggestion? * Sundry The review also listed a number of grammar errors, typos and suggestions relating to terminology These appear, on the whole, to have been accepted by the document editor (http://ops.ietf.org/lists/shim6/msg01774.html) * Changes to the shim message exchange Proposed in http://ops.ietf.org/lists/shim6/msg01756.html This suggestion appears to have been accepted by the document editor Also http://ops.ietf.org/lists/shim6/msg01758.html * Receiving Receiving payload without extension headers This suggestion appears to have been accepted by the document editor So we are almost ready with these documents, and as far as I can tell there is a rough consensus for the HBA and failure detection document, but a clear need to resolve the outstanding issues with the proto document and incorporate the changes as noted above. The three topics that I see from the mailing list as being unresolved at this stage are: * explicit shim6 error message (the lack thereof) Its not clear what the WG want to do on this. Suggestions? * TCP Checksum Failure Its not clear what the WG want to do on this. Suggestions? * Control Message length Text proposed (http://ops.ietf.org/lists/shim6/msg01780.html) Are we in agreement with this suggestion? thanks, Geoff & Kurtis Envelope-to: shim6-data@psg.com Delivery-date: Fri, 12 Jan 2007 17:16:23 +0000 Message-ID: <45A7C1D7.1000406@cs.uni-goettingen.de> Date: Fri, 12 Jan 2007 18:13:59 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: shim6@psg.com, hipsec-rg@honor.trusecure.com Subject: CFP: MobiArch'07 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit [Apologies if you receive multiple copies of this CFP] -------------------------------------------------------------------- The Second International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2007) Kyoto, Japan, August 27, 2007 (to be held with ACM SIGCOMM 2007, August 27-31, 2007) http://user.informatik.uni-goettingen.de/~mobiarch/2007 -------------------------------------------------------------------- With the recent development of technologies in wireless access and mobile devices, user, terminal, and network mobility has become an indispensable component of today's Internet vision, and it is likely to continue in the near future, while affecting the whole architectural design of the future Internet. Yet, issues like efficient mobility management and optimization, locator-identifier split, multihoming, security, and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles, and business models will require rethinking due to the massive penetration of mobility into the Internet. MobiArch'07 welcomes submissions, from both researchers and practitioners, in exploration of recent advances in architectures, protocols, and experiences with emerging technologies on wireless and mobility over the Internet, with an emphasis on wireless infrastructures and mobility patterns for mobility support, new mobility protocols, service discovery, routing and location management, mobile network performance evaluation and modeling, multi-homing, security, architectural impacts and deployment considerations. Topics of Interest: ================== Topics of MobiArch’07 cover all aspects of architectural issues and system support for wireless and mobility in the Internet, including but not limited to: - Impacts of new wireless technologies/services and mobility patterns on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link, network, transport to session/application layers and cross-layer design - Location management, positioning and data management systems for wireless and mobility - Routing and addressing, including locator/identifier split issues and their impacts to the Internet architecture - IP multihoming including flow distribution and load sharing for wireless and mobility - Performance evaluation, experimentation and modeling of mobility in the Internet - Accounting, access control, security and privacy issues and impacts to Internet architecture - Economic, scalability and deployment issues of mobility infrastructure design - Mechanisms and issues with connecting developing regions into the Internet Following the success of MobiArch'06, the MobiArch'07 workshop will be a single-track one-day workshop. Early stages, position papers, systems and measurement papers will be particularly welcome. The proceedings will be published by the ACM and ACM digital library. Submissions: =========== Submissions must be made to MobiArch'07 EDAS entry: http://edas.info/5238, following the guidelines in MobiArch'07 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/2007 Important Dates: =============== Abstract registration: March 20, 2007 Submission Deadline: March 27, 2007 Acceptance Notification: May 15, 2007 Camera-ready version due: June 12, 2007 MobiArch'07 Workshop: August 27, 2007 SIGCOMM'07: August 27-31, 2007 PROGRAM CO-CHAIRS ================= Xiaoming Fu, University of Goettingen (Germany) Katherine Guo, Bell Labs (USA) Sue Moon, KAIST (Korea) Ryuji Wakikawa, Keio University (Japan) PUBLICITY CHAIR =============== Jon Crowcroft, University of Cambridge (UK) QUESTIONS ========= Please consult the Program Co-Chairs (mobiarch@informatik.uni-goettingen.de) if you are uncertain whether your paper falls within the scope of the workshop. Envelope-to: shim6-data@psg.com Delivery-date: Tue, 09 Jan 2007 14:33:47 +0000 Date: Tue, 9 Jan 2007 09:29:34 -0500 From: Wesley Eddy To: Brian E Carpenter Cc: Iljitsch van Beijnum , shim6-wg , lars.eggert@nokia.com, simon.schuetz@netlab.nec.de Subject: Re: shim6-proto-07 review Message-ID: <20070109142934.GA6400@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i On Tue, Jan 09, 2007 at 11:43:15AM +0100, Brian E Carpenter wrote: > How does SCTP handle this problem? > Excerpted from RFC 2960: o The sender keeps a separate congestion control parameter set for each of the destination addresses it can send to (not each source-destination pair but for each destination). The parameters should decay if the address is not used for a long enough time period. o For each of the destination addresses, an endpoint does slow-start upon the first transmission to that address. This is pretty close to what's proposed in the TCP-RLCI draft designed to work with shim6 because it initializes a new congestion control parameter set (actually, it re-initializes the old set, but the effect is the same) and slow-starts after a failover event. -- Wesley M. Eddy Verizon Federal Network Systems Envelope-to: shim6-data@psg.com Delivery-date: Tue, 09 Jan 2007 10:45:53 +0000 Message-ID: <45A371C3.5070204@zurich.ibm.com> Date: Tue, 09 Jan 2007 11:43:15 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: weddy@grc.nasa.gov, shim6-wg Subject: Re: shim6-proto-07 review Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit How does SCTP handle this problem? Brian On 2007-01-08 19:22, Iljitsch van Beijnum wrote: > On 8-jan-2007, at 17:11, Wesley Eddy wrote: > >>> I think it's entirely reasonable for TCP or other transport protocols >>> to have different behaviors for path changes where the speed >>> difference is 1:2 vs where the speed difference is 1:1000. > >> Well, even though the speed of the links may be known, the amount of >> their capacity that is currently available at the time of a failover is >> probably much less well known to the shims. This knowledge also says >> nothing about the paths after those links. > > Sure, there is lots of stuff that we don't know. But when we have a 80 > Mbps stream going through a 100 Mbps or faster interface, and then the > path changes so that the next hop is over a 56 kbps interface, we know > that bad stuff is about to happen unless we take action. > >> One other point is that setting the congestion window to some percentage >> of its previous value based on the ratio of failover link capacity to >> primary link capacity is fairly naive, and ignores the significant >> amount of other relevent TCP state. > > In theory, the TCP window should be such that it throttles the data > stream to almost exactly the available bandwidth. In practice, this of > course doesn't work because the logic that determines the window size > isn't all that good. > > I don't think there is a simple action that can be taken that's always > the right response. The only thing I do know is that this is an issue > that we can't ignore, we must say _something_ in the protocol document > and hopefully the implementers will be smart enough to come up with > something reasonable or at least do some testing to avoid problems from > becoming too big when all of this hits the streets. > >> TCP can easily be >> smart enough to do the right thing if shim6 just lets it know that >> there's been a failover. > > Sounds good, except that not all failovers are created equal so some > additional information, when available, would be even better. Especially > as the main issue is going in and changing specifications and > implementations, making the list of signals a bit longer is > inconsequential. > > > Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 20:36:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: about the ULID in the TCP checksum Date: Mon, 8 Jan 2007 12:34:47 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FAE0@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: about the ULID in the TCP checksum Thread-Index: AcczUlnfhEn0g6NKTTaLuYq3v6G43QAEQCmA From: "Henderson, Thomas R" To: "Iljitsch van Beijnum" Cc: "shim6-wg" =20 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Monday, January 08, 2007 10:25 AM > To: Henderson, Thomas R > Cc: shim6-wg > Subject: Re: about the ULID in the TCP checksum >=20 > On 8-jan-2007, at 17:00, Henderson, Thomas R wrote: >=20 > > What do you mean, "detect incorrect shimming using the=20 > checksum"? Do > > you mean context confusion? I'm not sure it's any worse off. >=20 > For instance, when some bit error occurs (or, more realistically, a =20 > few) so context a001 becomes context b001. The addresses are =20 > rewritten as per the wrong context, the checksum doesn't find any =20 > fault and hopefully there will be a demuxing problem or a session =20 > ends up with incorrect data. >=20 I see. It seems that, for data insertion to occur, it would still require a shim6 checksum syndrome to another active context, matching also the ports and, for TCP, falling within the active window. But you would lose the additional checksum protection, I agree. Tom Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 18:25:40 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11C15A99-4672-4D53-9BE4-FBC5E1007275@muada.com> Cc: "shim6-wg" Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: about the ULID in the TCP checksum Date: Mon, 8 Jan 2007 19:25:12 +0100 To: "Henderson, Thomas R" On 8-jan-2007, at 17:00, Henderson, Thomas R wrote: > What do you mean, "detect incorrect shimming using the checksum"? Do > you mean context confusion? I'm not sure it's any worse off. For instance, when some bit error occurs (or, more realistically, a few) so context a001 becomes context b001. The addresses are rewritten as per the wrong context, the checksum doesn't find any fault and hopefully there will be a demuxing problem or a session ends up with incorrect data. Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 18:24:28 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <194F51AF-D59A-4BA0-B520-BCD897D8C9FB@muada.com> Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: shim6-proto-07 review Date: Mon, 8 Jan 2007 19:22:55 +0100 To: weddy@grc.nasa.gov On 8-jan-2007, at 17:11, Wesley Eddy wrote: >> I think it's entirely reasonable for TCP or other transport protocols >> to have different behaviors for path changes where the speed >> difference is 1:2 vs where the speed difference is 1:1000. > Well, even though the speed of the links may be known, the amount of > their capacity that is currently available at the time of a > failover is > probably much less well known to the shims. This knowledge also says > nothing about the paths after those links. Sure, there is lots of stuff that we don't know. But when we have a 80 Mbps stream going through a 100 Mbps or faster interface, and then the path changes so that the next hop is over a 56 kbps interface, we know that bad stuff is about to happen unless we take action. > One other point is that setting the congestion window to some > percentage > of its previous value based on the ratio of failover link capacity to > primary link capacity is fairly naive, and ignores the significant > amount of other relevent TCP state. In theory, the TCP window should be such that it throttles the data stream to almost exactly the available bandwidth. In practice, this of course doesn't work because the logic that determines the window size isn't all that good. I don't think there is a simple action that can be taken that's always the right response. The only thing I do know is that this is an issue that we can't ignore, we must say _something_ in the protocol document and hopefully the implementers will be smart enough to come up with something reasonable or at least do some testing to avoid problems from becoming too big when all of this hits the streets. > TCP can easily be > smart enough to do the right thing if shim6 just lets it know that > there's been a failover. Sounds good, except that not all failovers are created equal so some additional information, when available, would be even better. Especially as the main issue is going in and changing specifications and implementations, making the list of signals a bit longer is inconsequential. Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 16:15:01 +0000 Date: Mon, 8 Jan 2007 11:11:12 -0500 From: Wesley Eddy To: Iljitsch van Beijnum Cc: Brian Carpenter , shim6-wg , lars.eggert@nokia.com, simon.schuetz@netlab.nec.de Subject: Re: shim6-proto-07 review Message-ID: <20070108161112.GB30296@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i On Mon, Jan 08, 2007 at 04:34:10PM +0100, Iljitsch van Beijnum wrote: > > >We have actually discussed and worked on a solution to this in TCPM > >that > >is intended to work with shim6, among other protocols (including at > >least mip4, mip6, and hip): > >http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt > > Good, let's put in a reference. > > >I think this type of general solution is far preferable > >architecturally > >than asking shim6 to differentiate between path/interface > >properties and > >transport protocols and take special actions. > > If the information is available, it doesn't make sense to ignore it. > I think it's entirely reasonable for TCP or other transport protocols > to have different behaviors for path changes where the speed > difference is 1:2 vs where the speed difference is 1:1000. Well, even though the speed of the links may be known, the amount of their capacity that is currently available at the time of a failover is probably much less well known to the shims. This knowledge also says nothing about the paths after those links. For these reasons, TCP has to slow-start from an initial window anyways, so I do not see how specific knowledge about the links can be easily used. One other point is that setting the congestion window to some percentage of its previous value based on the ratio of failover link capacity to primary link capacity is fairly naive, and ignores the significant amount of other relevent TCP state. This is why I posted the link to the TCP-RLCI internet-draft that also updates the ssthresh, the rtt estimation, and the PMTUD state. TCP is too complex for the shim6 protocol to tell it _specifically_ what to do, but TCP can easily be smart enough to do the right thing if shim6 just lets it know that there's been a failover. The same goes for SCTP and DCCP. This is why I'd advise that asking the shim to publish a generic failover advertisement within the local stack is the extent of what is specified. -- Wesley M. Eddy Verizon Federal Network Systems Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 16:02:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: about the ULID in the TCP checksum Date: Mon, 8 Jan 2007 08:00:40 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FADA@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: about the ULID in the TCP checksum Thread-Index: AcczOtnQ+l3u0sjxT/K37rIL06Hq/gAAi0OA From: "Henderson, Thomas R" To: "Iljitsch van Beijnum" Cc: "shim6-wg" =20 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Monday, January 08, 2007 7:37 AM > To: Henderson, Thomas R > Cc: shim6-wg > Subject: Re: about the ULID in the TCP checksum >=20 > On 4-jan-2007, at 23:39, Henderson, Thomas R wrote: >=20 > >> If this is a problem, it's probably better to adjust the checksum > >> such that it appears to be correct to a non-shim6 aware observer. > >> This does have the downside that incorrect address rewriting isn't > >> detected by the checksum, though. >=20 > > Why not both twiddle the checksum at the shim so that it is=20 > aligned =20 > > with > > locators, and de-twiddle when deshimming? >=20 > I think I like this approach better than what's currently in=20 > the draft. >=20 > However, it does have a downside: since the checksum is=20 > adjusted when =20 > doing the shim processing, it's not possible to detect incorrect =20 > shimming using the checksum. >=20 What do you mean, "detect incorrect shimming using the checksum"? Do you mean context confusion? I'm not sure it's any worse off. Tom Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 15:37:24 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26E6A600-4583-4DC4-A559-BC4B34529421@muada.com> Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: about the ULID in the TCP checksum Date: Mon, 8 Jan 2007 16:36:58 +0100 To: "Henderson, Thomas R" On 4-jan-2007, at 23:39, Henderson, Thomas R wrote: >> If this is a problem, it's probably better to adjust the checksum >> such that it appears to be correct to a non-shim6 aware observer. >> This does have the downside that incorrect address rewriting isn't >> detected by the checksum, though. > Why not both twiddle the checksum at the shim so that it is aligned > with > locators, and de-twiddle when deshimming? I think I like this approach better than what's currently in the draft. However, it does have a downside: since the checksum is adjusted when doing the shim processing, it's not possible to detect incorrect shimming using the checksum. Envelope-to: shim6-data@psg.com Delivery-date: Mon, 08 Jan 2007 15:36:46 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C2B5C6C-39B0-49C7-9CF7-C97F3EE941CD@muada.com> Cc: Brian Carpenter , shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: shim6-proto-07 review Date: Mon, 8 Jan 2007 16:34:10 +0100 To: weddy@grc.nasa.gov On 3-jan-2007, at 17:20, Wesley Eddy wrote: > I'm all in favor of helping TCP to "do the right thing", but I think > this proposal (and specifically that suggested text) misses the mark. If someone cares to suggest something different... > If this direction were to be pursued, I'd recommend not making any > distinction between fast and slow interfaces, but rather specifying > one behavior that is followed in all cases. Let me explain why I make a big deal about the speed difference between the primary and the backup interface. When designing a multihomed network, the speed differences between the different possible configurations after different kinds of outages is an important concern. What I've seen in practice is that a backup that is 10% or less of the bandwidth of the original bandwidth used before the failure, is completely useless because congestion is immediate, persistent and fatal. I always recommend a minimum of 25% backup capacity. So far so good for multihomed _sites_ where these decisions are made explicitly. But shim6 can also easily work on a single host where the speed difference between the fastest interface (100 - 1000 Mbps) and the slowest (9.6 - 56 kbps) is easily four orders of magnitude. Ignoring this will create problems. > We have actually discussed and worked on a solution to this in TCPM > that > is intended to work with shim6, among other protocols (including at > least mip4, mip6, and hip): > http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt Good, let's put in a reference. > I think this type of general solution is far preferable > architecturally > than asking shim6 to differentiate between path/interface > properties and > transport protocols and take special actions. If the information is available, it doesn't make sense to ignore it. I think it's entirely reasonable for TCP or other transport protocols to have different behaviors for path changes where the speed difference is 1:2 vs where the speed difference is 1:1000. Envelope-to: shim6-data@psg.com Delivery-date: Thu, 04 Jan 2007 22:42:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: about the ULID in the TCP checksum Date: Thu, 4 Jan 2007 14:39:46 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FACA@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: about the ULID in the TCP checksum Thread-Index: AccvUF9KdnljuCvpSXqXEeZYho1ywQA/898g From: "Henderson, Thomas R" To: "Iljitsch van Beijnum" , "Brian E Carpenter" Cc: "shim6-wg" =20 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Wednesday, January 03, 2007 7:59 AM > To: Brian E Carpenter > Cc: shim6-wg > Subject: Re: about the ULID in the TCP checksum >=20 > If this is a problem, it's probably better to adjust the checksum =20 > such that it appears to be correct to a non-shim6 aware observer. =20 > This does have the downside that incorrect address rewriting isn't =20 > detected by the checksum, though. >=20 Why not both twiddle the checksum at the shim so that it is aligned with locators, and de-twiddle when deshimming? The implementation is fairly straightforward, to subtract off the ULID components of the checksum and add back the locator components (and vice versa). We've done this for our HIP implementation when substituting HITs for IP addresses, in certain configurations. Tom =20 Envelope-to: shim6-data@psg.com Delivery-date: Thu, 04 Jan 2007 08:36:19 +0000 Message-ID: <459CBC6F.8060801@zurich.ibm.com> Date: Thu, 04 Jan 2007 09:35:59 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: shim6-wg Subject: Re: about the ULID in the TCP checksum Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2007-01-03 16:59, Iljitsch van Beijnum wrote: > On 3-jan-2007, at 16:36, Brian E Carpenter wrote: > >>> "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP >>> packets with apparently incorrect checksums based on that fact alone >>> unless they implement (monitoring of) the full shim6 protocol and are >>> able to determine the checksum that must be present in a packet with >>> addresses rewritten by shim6." > >> I'm sorry, putting such an imperative in a shim6 RFC is an exercise >> in futility. You can certainly wish it to be true, but writing it >> in this way is pointless. > > I disagree. Although I recognize that middlebox makers will continue to > break protocols as they see fit, at least this provides guidance to > those middlebox makers who are on the fence. Writing as guidance is fine. Writing it as a SHALL NOT is meaningless. Logically, you can only address RFC 2119 language to the shim6 implementer. > >> And I repeat my suggestion of a probe mechanism to detect paths >> with this problem. > > Detecting paths where packets with apparent incorrect checksums are > discarded? That doesn't make much philosophical OR technical sense to me. Nevertheless, it would be an essential diagnostic tool (a TCP ping, in effect). > > If this is a problem, it's probably better to adjust the checksum such > that it appears to be correct to a non-shim6 aware observer. This does > have the downside that incorrect address rewriting isn't detected by the > checksum, though. Yep. This is a tricky point either way you solve it. Brian Envelope-to: shim6-data@psg.com Delivery-date: Thu, 04 Jan 2007 08:33:25 +0000 Message-ID: <459CBB60.1090101@zurich.ibm.com> Date: Thu, 04 Jan 2007 09:31:28 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: shim6-wg Subject: Re: shim6-proto-07 review Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2007-01-03 16:55, Iljitsch van Beijnum wrote: > On 3-jan-2007, at 16:33, Brian E Carpenter wrote: > >> Explain why TCP will react any differently to a sudden path >> change due to shim6, compared to a sudden path change for >> any other reason. I don't understand what is specific >> to shim6. > > The difference is that with shim6, we get to avoid massive congestion > when failing over from a very fast to a very slow path. I'm sorry, why is that different from regular routing failing over from a very fast to a very slow path? There's something I am completely missing here. Brian > > If there is no consensus for a general recommendation for slow start > when failing over, maybe we can make this specific to the situation > where a host fails over from a fast to a slow interface: > > "When the shim protocol triggers the selection of a new path, and this > path utilizes a lower-bandwidth interface than the interface of the > prior path, it is recommended that the TCP window for any affected TCP > sessions are reduced relative to the reduction in interface bandwidth. > Alternatively, TCP slow start can be initiated. For non-TCP protocols, > similar measures are recommended where available." > Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 16:23:40 +0000 Date: Wed, 3 Jan 2007 11:20:01 -0500 From: Wesley Eddy To: Iljitsch van Beijnum Cc: Brian E Carpenter , shim6-wg , lars.eggert@nokia.com, simon.schuetz@netlab.nec.de Subject: Re: shim6-proto-07 review Message-ID: <20070103162001.GA26447@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i On Wed, Jan 03, 2007 at 04:55:24PM +0100, Iljitsch van Beijnum wrote: > On 3-jan-2007, at 16:33, Brian E Carpenter wrote: > > >Explain why TCP will react any differently to a sudden path > >change due to shim6, compared to a sudden path change for > >any other reason. I don't understand what is specific > >to shim6. > > The difference is that with shim6, we get to avoid massive congestion > when failing over from a very fast to a very slow path. > > If there is no consensus for a general recommendation for slow start > when failing over, maybe we can make this specific to the situation > where a host fails over from a fast to a slow interface: > > "When the shim protocol triggers the selection of a new path, and > this path utilizes a lower-bandwidth interface than the interface of > the prior path, it is recommended that the TCP window for any > affected TCP sessions are reduced relative to the reduction in > interface bandwidth. Alternatively, TCP slow start can be initiated. > For non-TCP protocols, similar measures are recommended where > available." I'm all in favor of helping TCP to "do the right thing", but I think this proposal (and specifically that suggested text) misses the mark. If this direction were to be pursued, I'd recommend not making any distinction between fast and slow interfaces, but rather specifying one behavior that is followed in all cases. We have actually discussed and worked on a solution to this in TCPM that is intended to work with shim6, among other protocols (including at least mip4, mip6, and hip): http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt I think this type of general solution is far preferable architecturally than asking shim6 to differentiate between path/interface properties and transport protocols and take special actions. In my opinion, all that we need to ask of shim6 is that implementations provide some way for higher layers to recognize when a failover has occurred -- that failovers not be totally transparent. The details of how higher layers (including TCP) respond is up to them. -- Wesley M. Eddy Verizon Federal Network Systems Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 15:59:49 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: about the ULID in the TCP checksum Date: Wed, 3 Jan 2007 16:59:06 +0100 To: Brian E Carpenter On 3-jan-2007, at 16:36, Brian E Carpenter wrote: >> "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP >> packets with apparently incorrect checksums based on that fact >> alone unless they implement (monitoring of) the full shim6 >> protocol and are able to determine the checksum that must be >> present in a packet with addresses rewritten by shim6." > I'm sorry, putting such an imperative in a shim6 RFC is an exercise > in futility. You can certainly wish it to be true, but writing it > in this way is pointless. I disagree. Although I recognize that middlebox makers will continue to break protocols as they see fit, at least this provides guidance to those middlebox makers who are on the fence. > And I repeat my suggestion of a probe mechanism to detect paths > with this problem. Detecting paths where packets with apparent incorrect checksums are discarded? That doesn't make much philosophical OR technical sense to me. If this is a problem, it's probably better to adjust the checksum such that it appears to be correct to a non-shim6 aware observer. This does have the downside that incorrect address rewriting isn't detected by the checksum, though. Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 15:56:03 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EED4250-D5E2-4913-9BE3-12E605FB416A@muada.com> Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: shim6-proto-07 review Date: Wed, 3 Jan 2007 16:55:24 +0100 To: Brian E Carpenter On 3-jan-2007, at 16:33, Brian E Carpenter wrote: > Explain why TCP will react any differently to a sudden path > change due to shim6, compared to a sudden path change for > any other reason. I don't understand what is specific > to shim6. The difference is that with shim6, we get to avoid massive congestion when failing over from a very fast to a very slow path. If there is no consensus for a general recommendation for slow start when failing over, maybe we can make this specific to the situation where a host fails over from a fast to a slow interface: "When the shim protocol triggers the selection of a new path, and this path utilizes a lower-bandwidth interface than the interface of the prior path, it is recommended that the TCP window for any affected TCP sessions are reduced relative to the reduction in interface bandwidth. Alternatively, TCP slow start can be initiated. For non-TCP protocols, similar measures are recommended where available." Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 15:43:31 +0000 Message-ID: <459BCDE0.2050209@zurich.ibm.com> Date: Wed, 03 Jan 2007 16:38:08 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: marcelo bagnulo braun , shim6-wg Subject: Re: always including the context tag Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2007-01-02 14:56, Iljitsch van Beijnum wrote: > On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote: > >>> 1. Always including the context tag > >>> As I've said many times, it's a very bad idea to unnecessarily >>> increase overhead. > >> well, i think having an additional header is the clean way to do this, >> because there is an additional layer that is being inserted and the >> layer needs to perform its signalling and this is achieved using a >> extra header. > > Clean != best clean == best, all other things being equal. > > We also have ample precedent for non-clean solutions. :-) Yes, NAT for example... Brian Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 15:37:19 +0000 Message-ID: <459BCD88.9050600@zurich.ibm.com> Date: Wed, 03 Jan 2007 16:36:40 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: marcelo bagnulo braun , shim6-wg Subject: Re: about the ULID in the TCP checksum Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2007-01-02 15:27, Iljitsch van Beijnum wrote: > On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote: ... >> do you think we should add text about this? (if you do, please send text) > > "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP > packets with apparently incorrect checksums based on that fact alone > unless they implement (monitoring of) the full shim6 protocol and are > able to determine the checksum that must be present in a packet with > addresses rewritten by shim6." I'm sorry, putting such an imperative in a shim6 RFC is an exercise in futility. You can certainly wish it to be true, but writing it in this way is pointless. All you can do is insert a "middlebox considerations" section pointing out the failure cases and how they can be avoided. As I think I said the other day, this has to include TCP relays. And I repeat my suggestion of a probe mechanism to detect paths with this problem. Brian Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 15:35:51 +0000 Message-ID: <459BCCAF.3090708@zurich.ibm.com> Date: Wed, 03 Jan 2007 16:33:03 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: marcelo bagnulo braun , shim6-wg Subject: Re: shim6-proto-07 review Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Explain why TCP will react any differently to a sudden path change due to shim6, compared to a sudden path change for any other reason. I don't understand what is specific to shim6. Brian On 2007-01-03 12:38, Iljitsch van Beijnum wrote: > On 28-dec-2006, at 18:58, marcelo bagnulo braun wrote: > >>> There are no easy answers here, but congestion control is one of the >>> core concerns in the development of the internet, so I don't think we >>> can get away with ignoring this completely. > >> i can see this is an issue... > >> what do you suggest to do here? could you send text? > > Thinking a bit more about this, I keep coming back to TCP slow start... > >>> o Preserve established communications in the presence of certain >>> classes of failures, for example, TCP connections and UDP streams. > >>> Shouldn't this be "communication"? > >> i don't think so... > >> it could be Preserve an established communication or Preserve >> established communications > >> i think it is better the second one, because the first option seems we >> are talking about a given specific communication... > > Hm, isn't the word "communication" like "water"? I.e., you don't have > several of it, it's just one thing of which you have more or less. > >>> "The shim protocol is a site multihoming solution in the sense that >>> it allows existing communication to continue when a site that has >>> multiple connections to the internet experiences an outage on a >>> subset of these connections or further upstream. However, shim >>> processing is performed in individual hosts rather than through >>> site-wide mechanisms." > >> ok will add this... did you have a place in the draft you were >> thinking for this text? > > Maybe "placement of the shim", "terminology" or even "introduction"? > >>> the original locators become invalid at the same time and depending >>> on the time that is required to update the DNS and for those updates >>> to propagate. > >>> Why is the DNS relevant here? > >> because at least one valid locator must be published in the DNS in >> order for a shim host to be reachable, since the DNS is used as a >> rendez vous mechanism. OTOH, this is no specific of the shim6 >> protocol, but generic for any host... do you prefer we remove the DNS >> consideration from here? > > I don't understand what you mean here... The way I see it, the stuff > that's in the DNS doesn't change when there are outages, only when links > are added to or removed from the site. As such, the DNS timing is > irrelevant except in the corner case where all existing links are > replaced by all new ones or all the links that don't change go down. > >>> This makes me uncomfortable. How do you know that an address has >>> become terminally invalid, rather than accidentally unusable? > >> this was discussed during the last meeting in san diego and there was >> consensus that if a prefix is removed from the site, existing shim >> contexts that are using a ulid containing the prefix must be >> terminated when the prefix is removed. >> however, i read from your comment is that you don't have a problem >> with this idea but your problem is with how to implement this, right? > > Indeed. The autoconfig protocols don't have a mechanism to see the > difference between a router going down accidentally and administrative > removal of prefixes, unless you want to add significant amounts of > guesswork to the mix. And that's something I don't think is a good idea, > especially considering that in SITE multihoming the chances of clashing > ULIDs after renumbering are near-zero. > >> what about when the address becomes invalid? > > In many Unix stacks you can keep using an address even if it's removed > from all interfaces. This is a good thing, because it allows sessions to > survive short transitions such as moving out of radio range for a few > moments. With shim6 there is the potential that the address is gone for > a long time but it remains in use because the failure is repaired using > the shim. > > I think the best thing to do here is keep using the address for a > limited amount of time, like 1 - 24 hours. > >> in other words, i fail to see why this is easier to implement that >> what is currently in the draft. I mean, if the admin can determine the >> decomisioning time, it also can terminate the existing shim6 contexts... > > Of course not. A site administrator can't reach out into the state > inside all the hosts in the site... > >>> I don't see how regular nomadic behavior will result in two hosts >>> using the same address in quick succession, and they can further >>> reduce the potential for problems by not using temporary addresses as >>> ULIDs. > >> i am not sure what part of the draft this comment is referred to, but >> if a nomadic host creates a ulid using a temporary prefix and it moves >> away and then another nomadic hosts attaches itself to the same >> network and generates the same address, it is possible that the the >> two nomadic hosts end up using the same address. > > Right. So don't use this type of addresses as ULIDs and then there are > no problems. > >>> If the context establishment exchange fails, the initiator will >>> then know that the other end does not support shim6, and will >>> continue with standard unicast behavior for the session. > >>> Unicast? Shouldn't this be "single homed"? > >> will change to standard (non-shim6) behaviour, ok? > > Ok. > >>> More in general, the draft seems to suggest that the content of the >>> source address field in received packets may be ignored, > >> this is explicitly stated in the draft > > Hm, this makes me uncomfortable... As a receiver, I would much rather > know in advance which source addresses I'm going to see for established > sessions/context. > > Also, the source address can't be changed arbitrarily because then ICMP > messages don't make it back to the source. > >> the security level provided by the shim6 protocol relies on the >> context tag. Any attacker needs to learn the context tag before being >> able to inject addresses into an established context. It was concluded >> that this is an acceptable security level and similar to the one >> available in today's internet... do you agree? > > I don't know. In general, I'm not all that paranoid about security so > I'm not really the person to ask if security is good enough. :-) > >>> Bidirectional Communication (FBD). FBD uses a Keepalive message >>> which is sent when a host has received packets from its peer but has >>> not yet sent any packets from its ULP to the peer. > >>> No, this works per address (per locator even, not per ULID, IIRC), >>> not per ULP. > >> the meaning here is that FBD generates packets when the ULPs are >> silent. It doesn't mean that it generates packets per ULP, just that >> when all ULPs are silent, FBD generates packets. It may be rephrased >> as follows: > >> FBD uses a Keepalive message >> which is sent when a host has received packets from its peer but has >> not yet sent any packets from any of its ULPs to the peer. > >> would this be better? > > No, because I don't see what the ULP has to do with anything. FBD is > between address pairs. > >>> which precedes a routing header). When tunneling is used, whether >>> IP-in-IP tunneling or the special form of tunneling that Mobile IPv6 >>> uses (with Home Address Options and Routing header type 2), there is >>> a choice whether the shim applies inside the tunnel or outside the >>> tunnel, which affects the location of the shim6 header. > >>> How is this coordinated with the other side? If one side does >>> tunneling first and shim second and the other side the other way >>> around, there will be trouble. I don't see an easy way to avoid this. > >> the header order would be enough imho. I mean, when tunneling is >> performed, two IP layers are involved and each ip layer can have its >> own shim sublayer inside. So, for each ip layer a shim header can be >> added, so depending on the location of the shim header, how it >> applies, makes sense? > > Ok I don't see how it fails so I'll take your word for it... > >>> So what happens when some other header follows the shim header? Could >>> this be used for attacks? > >> this is for shim6 control messages and so far we haven't defined means >> to perform piggybacking of other protocols in shim6 control messages, >> so it is not possible for other protocols to follow the shim header. >> If this is defined in future extensions, they will need to update this >> part of the spec > > Well, wouldn't it be better then to forbid having additional headers > after the shim header? > >>> About the different messages: they are very similar. If I were to >>> implement all of this, I would rather work with one basic structure >>> for all of the messages, even if the _meaning_ of some fields is >>> different as long as their structure is always the same. I think this >>> can easily be done here, by including fields that nearly all messages >>> need (simply leave it zero when a particular message doesn't need a >>> field) and use options for things that a particular message needs >>> that aren't accommodated in the unified structure. > >> i can clearly see the cost of this approach, additional overhead for >> unused fields and potential source of confusion when fields change >> their name... what is the advantage of such approach? > > When you write an implementation, you need to extract all the values > from a header. Since these are all different sizes without natural > alignment this involves some complexity. When there are different > message headers, you need to do this multiple times. If there is only > one message header, you only have to implement the value extraction code > once. > > The field names aren't an issue at all. In code it works something like > this: > > void getheaders(int *field1, char *field2, unsigned int *field3); > > void lookatmessage1() > { > int contexttag; > char evilbit; > unsigned int remotecookie; > > getheaders(&contexttag, &evilbit, &remotecookie); > if (evilbit) > printf("You are breaking Evil Corp.'s patent, prepare to be sued!\n"); > } > > void lookatmessage2() > { > int contexttag; > char ossbit; > unsigned int localcookie; > > getheaders(&contexttag, &ossbit, &localcookie); > if (!ossbit) > printf("You are breaking the GPL, prepare to be sued!\n"); > } > > Since the formats are so similar already there are only 1 or 2 cases > where an unused field would be included so I don't think the overhead is > a concern. > >>> update request: why is this a request? > >> because this is a two way protocol, update and request... (i do agree >> that it is not the best name in this case... suggestion?) > > Just "update"? > >>> Hm, is it smart to defer verification here? > >> depending what verification we are talking about.... > >> this is explained in detail in section 7.2. Locator Verification > >> there are two type of verification HBA/CGA verification is one type >> and the other type is the one against flooding attakcs that is achived >> using a probe packets (of the path exploration protocol) > >> The spec in section 7.2 states that: > >> Thus the HBA/CGA >> verification SHOULD be performed by the host before the host >> acknowledges the new locator, by sending an Update Acknowledgement >> message, or an R2 message. > >> Before a host can use a locator (different than the ULID) as the >> destination locator it MUST perform the HBA/CGA verification if this >> was not performed before upon the reception of the locator set. In >> addition, it MUST verify that the ULID is indeed present at that >> locator. This verification is performed by doing a return- >> routability test as part of the Probe sub-protocol [9]. > >> makes sense? > > Is it useful to be able to defer locator verification? Simply doing it > immediately and either acknowledging that everything is ok or sending > back an error is much more robust than saying nothing and failing later. > >> When the traffic generated by the ULPs results in a bidirectional flow >> of packet between the peers, no extra packets need to be inserted. > >> is this ok? > > No, it's still confusing. Why not leave this up to the reachability draft? > >>> Ugh, this is certainly enough to make a grown man cry... Why all of >>> this alignment silliness? BGP works pretty well without it. > >> i think this is general in IPv6 protocols which are optimized for >> handling 64 bits units.... but maybe someone with more expertise can >> answer this one... > > Believe me, implementations aren't going to be any simpler because of > all the padding and length calculations, and the amounts of data > involved are so small that having faster copying because of the > alignment isn't an issue. > > [...] > >>> More in general, most error conditions are handled by silently >>> dropping packets, however, which is a very bad idea because that way, >>> there is no difference between an error and lost messages. > > [...] > >> sent this issue in a separate email > > IIRC this mail doesn't go into the issue of silently dropping messages, > so I'll restate my objection to that here. > >>> About the locator option: how many locators are allowed? > >> there is no upper limit other than the ones that fit inside a packet >> with the other required options... As i mentioned above, roughly this >> seemed enough not to become a limitation > > Some limit might be helpful, though. > >>> So this has nothing to do with RFC 3041 temporary addresses? > >> right > >>> In that case, a different name is probably better. > >> agree... what about "transient"? > > Sure. > >>> | E-FAILED | Context establishment exchange failed > >>> How do we know this, > >> becuase we have retried several times with I1 and never got a R1 back > >>> and is it necessary to explicitly take notice of this situation? > >> yes, so we don't try again for a while > >> makes sense? > > I prefer to have as few states as possible, but if you think having a > separate state here is helpful, I guess it isn't really harmful. > >>> Regarding section 7.9: shouldn't there be checks to make sure that >>> seemingly duplicate packets contain the same information as the >>> earlier packets they are supposedly the duplicate of? > >> I am not following you here... > >> are we talking about an initiator that receives a duplicate R1 back or >> a receiver that receives a duplicate I1? > >> If a receiver receives a duplicate I1 it doesn't do anything special, >> just replies with a R1. don't see any problem here > > So the issue whether it's a duplicate is irrelevant because the reply is > the same either way? > >> If an initiator receives a duplicated R1 (this may be due that the >> initiator have retried with multiple I1), it will process the first >> one received, and send a I2. The second one received, there will be no >> shim6 context in I1-SENT state, so it will be discarded. I do not see >> the point in verifying that the other information in the packet is ok >> or not... what would be the point in doing this verification? > > If you have special case handling for duplicates it's important to be > sure that you're actually dealing with duplicates. For instance, an > attack could be sending out fake shim6 packets so that when the real > ones come in later, those are rejected because they are presumed > duplicates. > >>> What if validators don't match? Eventually this shouldn't be a >>> problem but I expect some initial trouble here because you're doing >>> hashes over a fairly large number of values, a small mistake >>> somewhere means the hash doesn't work, some feedback in the form of >>> an error message would be good. > >> you mean for the first packet or for the following (duplicated) >> packets? for the first packet, this is a specific case of the general >> problem about whether it is ok to silently discard wrong packets (that >> i have initiated a new thread for this) >> For the second case, i don't see any point on doing this... > > Initial = when implementations first appear. > > It's important that people know what's going on in order to debug > problems, not only when doing interoperability testing, but also "in the > wild" later on. > >>> It occurs to me that there is nothing or very little in the protocol >>> that precludes shim negotiation using non-ULID addresses. > >> not sure what you mean by non ulid addresses.... > > In the case of unreachable ULIDs where the shim packets use locator > source/destination addresses. > >> if you mean that the shim protocol can support unreachable ULIDs like >> ULAs, then the answer is yes, it has been taken into account and >> should work fine with unreachable ulids...(you cannot do deferred >> setup but the spec supports it) > > Good. > >>> Adn why verify whether the source address is in Ls(peer)? The >>> security mechanisms do all the checking we need. > >> could you point me where is the text you are referring to? i mean >> there is no such verification in section 7.15 which was the section >> the previous comment was referring to... > > Page 59: > > If such a context exists in ESTABLISHED state, the host verifies that > the locator of the Initiator is included in Ls(peer) (This check is > unnecessary if there is no ULID-pair option in the I1 message). > > Page 63: > > o If the state is I1-SENT, then the host verifies if the source > locator is included in Ls(peer) or, it is included in the Locator > List contained in the the I2 message and the HBA/CGA verification > for this specific locator is successful > > Page 69: > > o If the state is I1-SENT, then the host verifies if the source > locator is included in Ls(peer) or, it is included in the Locator > List contained in the the I2 message and the HBA/CGA verification > for this specific locator is successful > > > o If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host > verifies if the source locator is included in Ls(peer) or, it is > included in the Locator List contained in the the I2 message and > the HBA/CGA verification for this specific locator is successful > > Page 74: > > Since context tags can be reused, the host MUST verify that the IPv6 > source address field is part of Ls(peer) and that the IPv6 > > Page 76: > > Since context tags can be reused, the host MUST verify that the IPv6 > source address field is part of Ls(peer) and that the IPv6 > destination address field is part of Ls(local). > > Page 81: > > o Other control messages (Update, Keepalive, Probe): Deliver to the > context with CT(local) equal to the Receiver Context Tag included > in the packet. Verify that the IPv6 source address field is part > of Ls(peer) and that the IPv6 destination address field is part of > Ls(local). If not, send a R1bis message. > >>> NO_R1_HOLDDOWN_TIME = 1 min > >>> ICMP_HOLDDOWN_TIME = 10 min > >>> This seems rather short, basically a shim host talking to a non-shim >>> host would retry setting up the shim every minute or every 10 minutes >>> even though there is good reason to assume this won't be successful. >>> Something like several hours seems more appropriate. (And only when >>> packets are actively exchanged.) > >> well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we >> retry when no R1 have been received. Note that this may be due to >> network outages that can be solved in a short time. So, we have a good >> reason to assume this will be successful, someone fixed the network >> path :-) > >> in the other case, i agree, what about: > >> NO_R1_HOLDDOWN_TIME = 5 min > >> ICMP_HOLDDOWN_TIME = 60 min > > The case where a firewall silently filters the packets is much more > likely. I still find what you list above rather short. > >>> The Locator List Option Format only specifies two verification >>> methods at this time: CGA or HBA. What about the case where a locator >>> can be verified using either CGA or HBA? Maybe it makes more sense to >>> have each method be a bit so they can be present or absent >>> independently. > >> if this turns to be useful we could define a verification code that >> would be CGA or HBA but i don't see why this would be useful... do you? > > I guess you can argue that if HBA verification is possible, there is > never a need to do CGA verification. > > Still, I think having bits for this rather than a single code is good > for two reasons: > > 1. In case someone wants to implement either HBA or CGA but not both for > IPR reasons, then it becomes useful to announce both HBA and CGA capability > > 2. So that when in the future a new verification method is introduced > that obviously isn't universally implemented but is better than CGA/HBA > in some way, so that people may want to take advantage of the new method > when supported but fall back on HBA/CGA if not > >>> Please make this "I. van Beijnum" > >> will try if the xml tool allows me to.... > > Please make sure this goes out correctly when it becomes an RFC. > Envelope-to: shim6-data@psg.com Delivery-date: Wed, 03 Jan 2007 11:40:48 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: shim6-proto-07 review Date: Wed, 3 Jan 2007 12:38:38 +0100 To: marcelo bagnulo braun On 28-dec-2006, at 18:58, marcelo bagnulo braun wrote: >> There are no easy answers here, but congestion control is one of >> the core concerns in the development of the internet, so I don't >> think we can get away with ignoring this completely. > i can see this is an issue... > what do you suggest to do here? could you send text? Thinking a bit more about this, I keep coming back to TCP slow start... >> o Preserve established communications in the presence of certain >> classes of failures, for example, TCP connections and UDP >> streams. >> Shouldn't this be "communication"? > i don't think so... > it could be Preserve an established communication or Preserve > established communications > i think it is better the second one, because the first option seems > we are talking about a given specific communication... Hm, isn't the word "communication" like "water"? I.e., you don't have several of it, it's just one thing of which you have more or less. >> "The shim protocol is a site multihoming solution in the sense >> that it allows existing communication to continue when a site that >> has multiple connections to the internet experiences an outage on >> a subset of these connections or further upstream. However, shim >> processing is performed in individual hosts rather than through >> site-wide mechanisms." > ok will add this... did you have a place in the draft you were > thinking for this text? Maybe "placement of the shim", "terminology" or even "introduction"? >> the original locators become invalid at the same time and >> depending >> on the time that is required to update the DNS and for those >> updates >> to propagate. >> Why is the DNS relevant here? > because at least one valid locator must be published in the DNS in > order for a shim host to be reachable, since the DNS is used as a > rendez vous mechanism. OTOH, this is no specific of the shim6 > protocol, but generic for any host... do you prefer we remove the > DNS consideration from here? I don't understand what you mean here... The way I see it, the stuff that's in the DNS doesn't change when there are outages, only when links are added to or removed from the site. As such, the DNS timing is irrelevant except in the corner case where all existing links are replaced by all new ones or all the links that don't change go down. >> This makes me uncomfortable. How do you know that an address has >> become terminally invalid, rather than accidentally unusable? > this was discussed during the last meeting in san diego and there > was consensus that if a prefix is removed from the site, existing > shim contexts that are using a ulid containing the prefix must be > terminated when the prefix is removed. > however, i read from your comment is that you don't have a problem > with this idea but your problem is with how to implement this, right? Indeed. The autoconfig protocols don't have a mechanism to see the difference between a router going down accidentally and administrative removal of prefixes, unless you want to add significant amounts of guesswork to the mix. And that's something I don't think is a good idea, especially considering that in SITE multihoming the chances of clashing ULIDs after renumbering are near- zero. > what about when the address becomes invalid? In many Unix stacks you can keep using an address even if it's removed from all interfaces. This is a good thing, because it allows sessions to survive short transitions such as moving out of radio range for a few moments. With shim6 there is the potential that the address is gone for a long time but it remains in use because the failure is repaired using the shim. I think the best thing to do here is keep using the address for a limited amount of time, like 1 - 24 hours. > in other words, i fail to see why this is easier to implement that > what is currently in the draft. I mean, if the admin can determine > the decomisioning time, it also can terminate the existing shim6 > contexts... Of course not. A site administrator can't reach out into the state inside all the hosts in the site... >> I don't see how regular nomadic behavior will result in two hosts >> using the same address in quick succession, and they can further >> reduce the potential for problems by not using temporary addresses >> as ULIDs. > i am not sure what part of the draft this comment is referred to, > but if a nomadic host creates a ulid using a temporary prefix and > it moves away and then another nomadic hosts attaches itself to the > same network and generates the same address, it is possible that > the the two nomadic hosts end up using the same address. Right. So don't use this type of addresses as ULIDs and then there are no problems. >> If the context establishment exchange fails, the initiator will >> then know that the other end does not support shim6, and will >> continue with standard unicast behavior for the session. >> Unicast? Shouldn't this be "single homed"? > will change to standard (non-shim6) behaviour, ok? Ok. >> More in general, the draft seems to suggest that the content of >> the source address field in received packets may be ignored, > this is explicitly stated in the draft Hm, this makes me uncomfortable... As a receiver, I would much rather know in advance which source addresses I'm going to see for established sessions/context. Also, the source address can't be changed arbitrarily because then ICMP messages don't make it back to the source. > the security level provided by the shim6 protocol relies on the > context tag. Any attacker needs to learn the context tag before > being able to inject addresses into an established context. It was > concluded that this is an acceptable security level and similar to > the one available in today's internet... do you agree? I don't know. In general, I'm not all that paranoid about security so I'm not really the person to ask if security is good enough. :-) >> Bidirectional Communication (FBD). FBD uses a Keepalive message >> which is sent when a host has received packets from its peer >> but has >> not yet sent any packets from its ULP to the peer. >> No, this works per address (per locator even, not per ULID, IIRC), >> not per ULP. > the meaning here is that FBD generates packets when the ULPs are > silent. It doesn't mean that it generates packets per ULP, just > that when all ULPs are silent, FBD generates packets. It may be > rephrased as follows: > FBD uses a Keepalive message > which is sent when a host has received packets from its peer but > has > not yet sent any packets from any of its ULPs to the peer. > would this be better? No, because I don't see what the ULP has to do with anything. FBD is between address pairs. >> which precedes a routing header). When tunneling is used, whether >> IP-in-IP tunneling or the special form of tunneling that Mobile >> IPv6 >> uses (with Home Address Options and Routing header type 2), >> there is >> a choice whether the shim applies inside the tunnel or outside the >> tunnel, which affects the location of the shim6 header. >> How is this coordinated with the other side? If one side does >> tunneling first and shim second and the other side the other way >> around, there will be trouble. I don't see an easy way to avoid this. > the header order would be enough imho. I mean, when tunneling is > performed, two IP layers are involved and each ip layer can have > its own shim sublayer inside. So, for each ip layer a shim header > can be added, so depending on the location of the shim header, how > it applies, makes sense? Ok I don't see how it fails so I'll take your word for it... >> So what happens when some other header follows the shim header? >> Could this be used for attacks? > this is for shim6 control messages and so far we haven't defined > means to perform piggybacking of other protocols in shim6 control > messages, so it is not possible for other protocols to follow the > shim header. If this is defined in future extensions, they will > need to update this part of the spec Well, wouldn't it be better then to forbid having additional headers after the shim header? >> About the different messages: they are very similar. If I were to >> implement all of this, I would rather work with one basic >> structure for all of the messages, even if the _meaning_ of some >> fields is different as long as their structure is always the same. >> I think this can easily be done here, by including fields that >> nearly all messages need (simply leave it zero when a particular >> message doesn't need a field) and use options for things that a >> particular message needs that aren't accommodated in the unified >> structure. > i can clearly see the cost of this approach, additional overhead > for unused fields and potential source of confusion when fields > change their name... what is the advantage of such approach? When you write an implementation, you need to extract all the values from a header. Since these are all different sizes without natural alignment this involves some complexity. When there are different message headers, you need to do this multiple times. If there is only one message header, you only have to implement the value extraction code once. The field names aren't an issue at all. In code it works something like this: void getheaders(int *field1, char *field2, unsigned int *field3); void lookatmessage1() { int contexttag; char evilbit; unsigned int remotecookie; getheaders(&contexttag, &evilbit, &remotecookie); if (evilbit) printf("You are breaking Evil Corp.'s patent, prepare to be sued! \n"); } void lookatmessage2() { int contexttag; char ossbit; unsigned int localcookie; getheaders(&contexttag, &ossbit, &localcookie); if (!ossbit) printf("You are breaking the GPL, prepare to be sued!\n"); } Since the formats are so similar already there are only 1 or 2 cases where an unused field would be included so I don't think the overhead is a concern. >> update request: why is this a request? > because this is a two way protocol, update and request... (i do > agree that it is not the best name in this case... suggestion?) Just "update"? >> Hm, is it smart to defer verification here? > depending what verification we are talking about.... > this is explained in detail in section 7.2. Locator Verification > there are two type of verification HBA/CGA verification is one type > and the other type is the one against flooding attakcs that is > achived using a probe packets (of the path exploration protocol) > The spec in section 7.2 states that: > Thus the HBA/CGA > verification SHOULD be performed by the host before the host > acknowledges the new locator, by sending an Update Acknowledgement > message, or an R2 message. > Before a host can use a locator (different than the ULID) as the > destination locator it MUST perform the HBA/CGA verification if > this > was not performed before upon the reception of the locator set. In > addition, it MUST verify that the ULID is indeed present at that > locator. This verification is performed by doing a return- > routability test as part of the Probe sub-protocol [9]. > makes sense? Is it useful to be able to defer locator verification? Simply doing it immediately and either acknowledging that everything is ok or sending back an error is much more robust than saying nothing and failing later. > When the traffic generated by the ULPs results in a bidirectional > flow of packet between the peers, no extra packets need to be > inserted. > is this ok? No, it's still confusing. Why not leave this up to the reachability draft? >> Ugh, this is certainly enough to make a grown man cry... Why all >> of this alignment silliness? BGP works pretty well without it. > i think this is general in IPv6 protocols which are optimized for > handling 64 bits units.... but maybe someone with more expertise > can answer this one... Believe me, implementations aren't going to be any simpler because of all the padding and length calculations, and the amounts of data involved are so small that having faster copying because of the alignment isn't an issue. [...] >> More in general, most error conditions are handled by silently >> dropping packets, however, which is a very bad idea because that >> way, there is no difference between an error and lost messages. [...] > sent this issue in a separate email IIRC this mail doesn't go into the issue of silently dropping messages, so I'll restate my objection to that here. >> About the locator option: how many locators are allowed? > there is no upper limit other than the ones that fit inside a > packet with the other required options... As i mentioned above, > roughly this seemed enough not to become a limitation Some limit might be helpful, though. >> So this has nothing to do with RFC 3041 temporary addresses? > right >> In that case, a different name is probably better. > agree... what about "transient"? Sure. >> | E-FAILED | Context establishment exchange failed >> How do we know this, > becuase we have retried several times with I1 and never got a R1 back >> and is it necessary to explicitly take notice of this situation? > yes, so we don't try again for a while > makes sense? I prefer to have as few states as possible, but if you think having a separate state here is helpful, I guess it isn't really harmful. >> Regarding section 7.9: shouldn't there be checks to make sure that >> seemingly duplicate packets contain the same information as the >> earlier packets they are supposedly the duplicate of? > I am not following you here... > are we talking about an initiator that receives a duplicate R1 back > or a receiver that receives a duplicate I1? > If a receiver receives a duplicate I1 it doesn't do anything > special, just replies with a R1. don't see any problem here So the issue whether it's a duplicate is irrelevant because the reply is the same either way? > If an initiator receives a duplicated R1 (this may be due that the > initiator have retried with multiple I1), it will process the first > one received, and send a I2. The second one received, there will be > no shim6 context in I1-SENT state, so it will be discarded. I do > not see the point in verifying that the other information in the > packet is ok or not... what would be the point in doing this > verification? If you have special case handling for duplicates it's important to be sure that you're actually dealing with duplicates. For instance, an attack could be sending out fake shim6 packets so that when the real ones come in later, those are rejected because they are presumed duplicates. >> What if validators don't match? Eventually this shouldn't be a >> problem but I expect some initial trouble here because you're >> doing hashes over a fairly large number of values, a small mistake >> somewhere means the hash doesn't work, some feedback in the form >> of an error message would be good. > you mean for the first packet or for the following (duplicated) > packets? for the first packet, this is a specific case of the > general problem about whether it is ok to silently discard wrong > packets (that i have initiated a new thread for this) > For the second case, i don't see any point on doing this... Initial = when implementations first appear. It's important that people know what's going on in order to debug problems, not only when doing interoperability testing, but also "in the wild" later on. >> It occurs to me that there is nothing or very little in the >> protocol that precludes shim negotiation using non-ULID addresses. > not sure what you mean by non ulid addresses.... In the case of unreachable ULIDs where the shim packets use locator source/destination addresses. > if you mean that the shim protocol can support unreachable ULIDs > like ULAs, then the answer is yes, it has been taken into account > and should work fine with unreachable ulids...(you cannot do > deferred setup but the spec supports it) Good. >> Adn why verify whether the source address is in Ls(peer)? The >> security mechanisms do all the checking we need. > could you point me where is the text you are referring to? i mean > there is no such verification in section 7.15 which was the section > the previous comment was referring to... Page 59: If such a context exists in ESTABLISHED state, the host verifies that the locator of the Initiator is included in Ls(peer) (This check is unnecessary if there is no ULID-pair option in the I1 message). Page 63: o If the state is I1-SENT, then the host verifies if the source locator is included in Ls(peer) or, it is included in the Locator List contained in the the I2 message and the HBA/CGA verification for this specific locator is successful Page 69: o If the state is I1-SENT, then the host verifies if the source locator is included in Ls(peer) or, it is included in the Locator List contained in the the I2 message and the HBA/CGA verification for this specific locator is successful o If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host verifies if the source locator is included in Ls(peer) or, it is included in the Locator List contained in the the I2 message and the HBA/CGA verification for this specific locator is successful Page 74: Since context tags can be reused, the host MUST verify that the IPv6 source address field is part of Ls(peer) and that the IPv6 Page 76: Since context tags can be reused, the host MUST verify that the IPv6 source address field is part of Ls(peer) and that the IPv6 destination address field is part of Ls(local). Page 81: o Other control messages (Update, Keepalive, Probe): Deliver to the context with CT(local) equal to the Receiver Context Tag included in the packet. Verify that the IPv6 source address field is part of Ls(peer) and that the IPv6 destination address field is part of Ls(local). If not, send a R1bis message. >> NO_R1_HOLDDOWN_TIME = 1 min >> ICMP_HOLDDOWN_TIME = 10 min >> This seems rather short, basically a shim host talking to a non- >> shim host would retry setting up the shim every minute or every 10 >> minutes even though there is good reason to assume this won't be >> successful. Something like several hours seems more appropriate. >> (And only when packets are actively exchanged.) > well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we > retry when no R1 have been received. Note that this may be due to > network outages that can be solved in a short time. So, we have a > good reason to assume this will be successful, someone fixed the > network path :-) > in the other case, i agree, what about: > NO_R1_HOLDDOWN_TIME = 5 min > ICMP_HOLDDOWN_TIME = 60 min The case where a firewall silently filters the packets is much more likely. I still find what you list above rather short. >> The Locator List Option Format only specifies two verification >> methods at this time: CGA or HBA. What about the case where a >> locator can be verified using either CGA or HBA? Maybe it makes >> more sense to have each method be a bit so they can be present or >> absent independently. > if this turns to be useful we could define a verification code that > would be CGA or HBA but i don't see why this would be useful... do > you? I guess you can argue that if HBA verification is possible, there is never a need to do CGA verification. Still, I think having bits for this rather than a single code is good for two reasons: 1. In case someone wants to implement either HBA or CGA but not both for IPR reasons, then it becomes useful to announce both HBA and CGA capability 2. So that when in the future a new verification method is introduced that obviously isn't universally implemented but is better than CGA/ HBA in some way, so that people may want to take advantage of the new method when supported but fall back on HBA/CGA if not >> Please make this "I. van Beijnum" > will try if the xml tool allows me to.... Please make sure this goes out correctly when it becomes an RFC. Envelope-to: shim6-data@psg.com Delivery-date: Tue, 02 Jan 2007 14:28:11 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: about the ULID in the TCP checksum Date: Tue, 2 Jan 2007 15:27:34 +0100 To: marcelo bagnulo braun On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote: >> The problem here is that some intermediate system, such as a >> firewall or a smart NIC, may take it upon itself to check the TCP >> or UDP checksum and discard the packet if the checksum fails. > how common is this practice? is this widely used? Certainly not with IPv6. But checksumming NICs are very common for IPv4 so I'm sure we'll have those for IPv6 too in the future. And at one point, PIX firewalls would truncate DNS packets that were longer than 512 bytes, creating much mayham with EDNS0. So I have a healthy suspicion of firewall builders. >> For firewalls and the like, the best thing is probably either to >> fully monitor the shim state so they can do this properly, or >> forego such checking if a shim header is present. > yes, this is probably useful in terms of security also, just like > in the case to TCP connections, where the firewall can decide to > accept segments of connections for which the firewall have > previosuly seen SYN exchange > do you think we should add text about this? (if you do, please send > text) "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP packets with apparently incorrect checksums based on that fact alone unless they implement (monitoring of) the full shim6 protocol and are able to determine the checksum that must be present in a packet with addresses rewritten by shim6." >> For NICs a better solution would be to do an incremental checksum >> verification and only over the ULP segment, so that the host stack >> must complete the calculation by applying the increment from the >> pseudo header, which can largely be cached, so the performance >> advantages are almost completely preserved > i don't understand what do you mean by incremental checksum > verification... could you expand on this? The checksum is defined as the one's complement of the one's complement additions of the 16-bit words making up the pseudo-header and the TCP/UDP/ICMP segment. So you could calculate it this way: // 0 start chksm = 0; // 1 pseudoheader for (i = 0; i < pseudo.length; i++) chcksm = 1cmpadd(chcksm, pseudo.hdr[i]); // 2 TCP for (i = 0; i < tcp.length; i++) chcksm = 1cmpadd(chcksm, tcp.data[i]); // 3 check if (1cmp(chcksm) == tcp.checksum) return happy; else return sad; As far as I can tell, NICs can do parts 0 - 2 and leave 3 up to the IP stack. This method isn't compatible with shim6 because then the NIC would have to be aware of the address rewriting. However, it wouldn't be hard to do 0 and 1 in the IP stack, 2 in the NIC and 3 in the IP stack again. Since the pseudoheader is always the same for a session, this part can be pre-computed, so the only part that actually requires real work is checking the TCP/UDP/ICMP segment, which is exactly the part that still happens in the NIC, so performance can be the same but now everything is shim-compatible. Envelope-to: shim6-data@psg.com Delivery-date: Tue, 02 Jan 2007 14:11:57 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: length of shim6 control mesages Date: Tue, 2 Jan 2007 15:11:30 +0100 To: marcelo bagnulo braun On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote: > so far we haven't considered the case where the options wouldn't > fit in one packet... 1280 bytes seems big enough.... Famous last words. :-) > what do you suggest? Some language that tells implementers whether they can make shim6 packets that result in IPv6 packets bigger than 1280 bytes. For instance: "Shim6 signalling packets may not be larger than 1280 bytes, including the IPv6 header and any intermediate headers between the IPv6 header and the shim6 header. One way to meet this requirement is to omit part of the locator address information if with this information included, the packet would become larger than 1280 bytes. An implementation may impose administrative restrictions to avoid excessively large shim6 packets, such as a limitation on the number of locators to be used or a limitation on the CGA key size." Envelope-to: shim6-data@psg.com Delivery-date: Tue, 02 Jan 2007 14:10:27 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: about the protection against on path attackers Date: Tue, 2 Jan 2007 15:04:37 +0100 To: marcelo bagnulo braun On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote: >> Also, for CGA verification, don't we need to send the other side a >> challenge to avoid replays? > I don't know if this is necessary... Ah, ok, so the updates are their own challenge. What I was thinking about was that the correspondent claims to have the secret key belonging to the public key, but you don't know that unless you see some data signed with the secret key that is particular to the session at hand. >> context. In this case, we are in the Context confusion >> situation, >> and the host MUST NOT use the old context to send any >> packets. It >> MAY just discard the old context (after all, the peer has >> discarded it), or it MAY attempt to re-establish the old >> context >> by sending a new I1 message and moving its state to I1- >> SENT. In >> any case, once that this situation is detected, the host >> MUST NOT >> keep two contexts with overlapping Ls(peer) locator sets and >> the >> same context tag in ESTABLISHED state, since this would >> result in >> demultiplexing problems on the peer. >> What if an attacker is trying to interfere with legitimate >> communication? We must be VERY sure that the new shim messages >> come from the same host as the one that created the existing state >> if we're going to mess with that existing state. > THe current security level is that we don't provide protection > against on path attackers. If an attacker learns the context tag, > then it can do some nasty stuff, including destroying the > established context. this is the level of security that we have > defined for the protocol. We can discuss whether this security > level is approapriate, but i would like to have a high level > discussion on the issue. I guess you're right. But as an added measure, I'd like to see that the old context isn't torn down until the new one is set up completely. This way, an attacker that somehow finds out a context tag needs to have return routability and do the full 4-way handshake to destroy a context, which is almost certainly not worth that much trouble. Envelope-to: shim6-data@psg.com Delivery-date: Tue, 02 Jan 2007 13:59:13 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4EEA8363-A438-460C-AA71-2B352B88D256@muada.com> Cc: shim6-wg Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: always including the context tag Date: Tue, 2 Jan 2007 14:56:17 +0100 To: marcelo bagnulo braun On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote: >> 1. Always including the context tag >> As I've said many times, it's a very bad idea to unnecessarily >> increase overhead. > well, i think having an additional header is the clean way to do > this, because there is an additional layer that is being inserted > and the layer needs to perform its signalling and this is achieved > using a extra header. Clean != best We also have ample precedent for non-clean solutions. :-) >> Earlier, I proposed to include a mandatory way for a host to >> instruct its peer to not include the shim header, pending >> mechanisms to do demultiplexing without the context tag. After >> reading the draft, I realize that this imposes some extra ICMP >> demultiplexing difficulties on implementations. > depending on which fields do you use for the demux, i guess... i > mean if you use the flow label, there wouldn't be additional > problems, i think, right? Right, but that's not a discussion that we need to have. What I advocate is having the receiver tell the sender that it must not include the header because the receiver can demux. How the receiver does this is up to the receiver and doesn't need to be part of this spec. (The most obvious choice is having locator-only addresses for each ULID address so there is always an unambigious identification of packets sent to locators and an unambiguous mapping back to the ULID.) >> So if the wg doesn't want to include this mandatory option, I >> suggest something different: since the traffic engineering >> mechanisms aren't really developed anyway and this problem is >> related to that, simply remove the locator preferences mechanism >> so that the context tag suppression can be included when proper >> traffic engineering is added. > i don't think this is such a good idea... > i mean i think locator preferneces are useful, i don't see why we > should remove them from the spec... They're useful, but if we have locator preferences and not context tag suppression, this creates the opportunity for using shim6 as a load balancing mechanism that introduces additional per-packet overhead in cases where there is no failure. This is a very bad thing, in my opinion. So that's why I think if we can't agree on the CT suppression in this spec, we should also remove the preferences and then introduce both of them at some later date, along with a more comprehensive traffic engineering solution, because the preferences alone aren't enough for that anyway. Envelope-to: shim6-data@psg.com Delivery-date: Mon, 01 Jan 2007 12:04:40 +0000 Message-ID: <4598F77C.8000004@zurich.ibm.com> Date: Mon, 01 Jan 2007 12:58:52 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Iljitsch van Beijnum , shim6-wg Subject: Re: always including the context tag Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2006-12-28 18:57, marcelo bagnulo braun wrote: > In his review Iljitsch raises the following issue: > > my comments are online: > > please comment on the issue related to if we should support other > mechanisms for demux other than the context tag contained in the shim > payload header > >> 1. Always including the context tag >> >> As I've said many times, it's a very bad idea to unnecessarily >> increase overhead. Has anyone looked at how this would interact with ROHC? The only context in which I would agree with Iljitsch is where bandwidth is precious, and that is exactly where ROHC should be used anyway. The context tag really should be very compressible... > > well, i think having an additional header is the clean way to do this, > because there is an additional layer that is being inserted and the > layer needs to perform its signalling and this is achieved using a extra > header. Yes, and an architecturally clean solution may quite legitimately make it necessary to increase overhead. Brian > >> Not only is this a bad thing in and of itself, but it also doesn't >> help convince people to forego IPv4+BGP in favor of IPv6+shim. >> >> Now if we only include the shim header containing the context tag >> after a failure, this could be a reasonable tradeoff. However, I'm >> quite sure that if and when shim6 is adopted, some people will use it >> to manage their traffic engineering by doing a locator change >> immediately and proceed in a shimmed state for the rest of the >> communication session. >> >> Earlier, I proposed to include a mandatory way for a host to instruct >> its peer to not include the shim header, pending mechanisms to do >> demultiplexing without the context tag. After reading the draft, I >> realize that this imposes some extra ICMP demultiplexing difficulties >> on implementations. > > depending on which fields do you use for the demux, i guess... i mean if > you use the flow label, there wouldn't be additional problems, i think, > right? > >> So if the wg doesn't want to include this mandatory option, I suggest >> something different: since the traffic engineering mechanisms aren't >> really developed anyway and this problem is related to that, simply >> remove the locator preferences mechanism so that the context tag >> suppression can be included when proper traffic engineering is added. >> > > i don't think this is such a good idea... > > i mean i think locator preferneces are useful, i don't see why we should > remove them from the spec... > > >> Also see draft-van-beijnum-shim6-suppress-header-00.txt (do it while >> you can, it expires next week...), this outlines a more fully formed >> mechanism to suppress the context tag header. >> >> I would very much like to see a consensus call on this subject. >> >> > > Envelope-to: shim6-data@psg.com Delivery-date: Mon, 01 Jan 2007 12:04:31 +0000 Message-ID: <4598F8B2.2090002@zurich.ibm.com> Date: Mon, 01 Jan 2007 13:04:02 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Iljitsch van Beijnum , shim6-wg Subject: Re: about the ULID in the TCP checksum Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2006-12-28 18:57, marcelo bagnulo braun wrote: > Iljitsch in his review raises the following issue: > > my comments are inline > >> The result of this consistent mapping is that there is no impact on >> the ULPs. In particular, there is no impact on pseudo-header >> checksums and connection identification. >> >> >> The problem here is that some intermediate system, such as a firewall >> or a smart NIC, may take it upon itself to check the TCP or UDP >> checksum and discard the packet if the checksum fails. > > how common is this practice? is this widely used? I've not heard of firewalls doing this, but TCP relays are a known form of evil - probably shim6 would not work on such a path. TCP/IP offload mechanisms in general will have to be shim6-aware, for sure. This is going to be very common in server clusters. (In general, do we need a TCP/shim6 probing procedure, to check whether a path actually works?) Brian > >> For firewalls and the like, the best thing is probably either to >> fully monitor the shim state so they can do this properly, or forego >> such checking if a shim header is present. >> > > yes, this is probably useful in terms of security also, just like in the > case to TCP connections, where the firewall can decide to accept > segments of connections for which the firewall have previosuly seen SYN > exchange > > do you think we should add text about this? (if you do, please send text) > >> For NICs a better solution would be to do an incremental checksum >> verification and only over the ULP segment, so that the host stack >> must complete the calculation by applying the increment from the >> pseudo header, which can largely be cached, so the performance >> advantages are almost completely preserved > > i don't understand what do you mean by incremental checksum > verification... could you expand on this? > > Envelope-to: shim6-data@psg.com Delivery-date: Mon, 01 Jan 2007 11:54:40 +0000 Message-ID: <4598F5F4.5010500@zurich.ibm.com> Date: Mon, 01 Jan 2007 12:52:20 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Iljitsch van Beijnum , shim6-wg Subject: Re: error messages in shim6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2006-12-28 14:29, marcelo bagnulo braun wrote: > Iljitsch has brought up the following issue in his review: > >> More in general, most error conditions are handled by silently >> dropping packets, however, which is a very bad idea because that way, >> there is no difference between an error and lost messages. >> So in some cases, a host may continue to resend the offending packet >> because it doesn't know something went wrong. The main problem with >> this approach is that you can't debug it from one end: you need to see >> what happens on both ends to determine why something doesn't work. >> >> Silently dropping packets because of errors is the right approach for >> security reasons in some cases, but I don't think this applies here. A >> short error message with an error code and optionally a human-readable >> message would be much better. As long as these error packets are >> smaller than the packets that trigger them, there should be little or >> no security impact, especially considering that we're prepared to talk >> shim with the correspondent in question to begin with. >> > > his proposal as you can see is to include a shim6 error message to > handle this situations... any opinions? I would agree with Iljitsch for any case where the sender will indeed continuously repeat the message unless there is a response. (Alternatively, get rid of the continuous repeats some other way.) Brian