idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-sec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2013) is 4028 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-manet-rfc6622-bis-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) U. Herberg 3 Internet-Draft Fujitsu Laboratories of America 4 Updates: RFC6130 C. Dearlove 5 (if approved) BAE Systems ATC 6 Intended status: Standards Track T. Clausen 7 Expires: October 17, 2013 LIX, Ecole Polytechnique 8 April 15, 2013 10 Integrity Protection for Control Messages in NHDP and OLSRv2 11 draft-ietf-manet-nhdp-olsrv2-sec-02 13 Abstract 15 This document specifies integrity and replay protection for required 16 implementation in the MANET Neighborhood Discovery Protocol (NHDP) 17 and the Optimized Link State Routing Protocol version 2 (OLSRv2). 18 This document specifies how an included integrity check value (ICV) 19 and a timestamp TLV, defined in RFC6622bis, are used by NHDP and 20 OLSRv2 for countering a number of security threats. The ICV TLV uses 21 a SHA-256 based HMAC and one or more shared secret keys. The 22 timestamp TLV is based on POSIX time, and assumes that the clocks in 23 all routers in the network can be synchronized with sufficient 24 precision. The mechanism in this specification can also be used for 25 other MANET protocols using RFC5444. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 17, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 64 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 65 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Message Generation and Processing . . . . . . . . . . . . . . 8 67 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 68 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9 69 6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10 70 6.3.1. Validating a Message Based on Timestamp . . . . . . . 10 71 6.3.2. Validating a Message Based on Integrity Check . . . . 11 72 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 12 76 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 12 77 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 12 78 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12 79 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 81 11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This specification defines a framework of security mechanisms that 87 must be included in conforming implementations of the Neighborhood 88 Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State 89 Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc 90 NETworks (MANETs). A deployment of these protocols may choose to 91 employ alternative(s) to these mechanisms, in particular it may 92 choose to protect packets rather than messages, it may choose to use 93 an alternative integrity check value (ICV) with preferred properties, 94 and/or it may use an alternative timestamp. A deployment may choose 95 to use no such security mechanisms, but this is not recommended. 97 The mechanisms specified are the use of an ICV for protection of the 98 protocols' control messages, and the use of timestamps in those 99 messages to prevent replay attacks. Both use the TLV mechanism 100 specified in [RFC5444] to add this information to the messages. 101 These ICV and timestamp TLVs are defined in [RFC6622bis]. Different 102 ICV TLVs are used for HELLO messages in NHDP and TC messages in 103 OLSRv2, the former also protecting the source address of the IP 104 datagram that contains the HELLO message. This is because the IP 105 datagram source address is used by NHDP to determine the address of a 106 neighbor interface, and is not necessarily otherwise contained in the 107 HELLO message, while OLSRv2's TC message is forwarded in a new 108 packet, and thus has no single IP datagram source address. 110 The mechanism specified in this document exists between NHDP's and 111 OLSRv2's message processing/generation and the [RFC5444] packet 112 parsing/generation, as illustrated in Figure 1. 114 | | 115 Incoming | /|\ Outgoing 116 packet \|/ | packet 117 | | 118 +--------------------------------+ 119 | | 120 | RFC5444 packet | 121 | parsing / generation | 122 | | 123 +--------------------------------+ 124 | | 125 Messages | /|\ Messages with 126 \|/ | added TLVs 127 | | 128 D +--------------------------------+ 129 R /__________________ | | 130 O \ Messages | This specification | 131 P (failed check) | | 132 +--------------------------------+ 133 | | 134 Messages | /|\ Messages 135 (passed check) \|/ | 136 | | 137 +--------------------------------+ 138 | | 139 | NHDP/OLSRv2 message | 140 | processing / generation | 141 | | 142 +--------------------------------+ 144 Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in 151 [RFC2119]. 153 Additionally, this document uses the terminology of [RFC5444], 154 [RFC6130], [OLSRv2], and [RFC6622bis]. 156 3. Applicability Statement 158 [RFC6130] and [OLSRv2] enable extensions to recognize additional 159 reasons for rejecting a message as "badly formed and therefore 160 invalid for processing", and mention security (integrity protection) 161 as an explicit example. This document specifies a framework that 162 provides this functionality. 164 Implementations of [RFC6130] and [OLSRv2] MUST include this 165 framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this 166 framework, except for when a different security mechanism is more 167 appropriate. 169 The applicability of this framework is determined by its 170 characteristics, which are that it: 172 o Specifies a security framework that is required to be included in 173 conforming implementations of [RFC6130] and [OLSRv2]. 175 o Specifies an association of ICVs with messages, and for using 176 missing or invalid ICVs as such an additional reason for rejecting 177 a message as "badly formed and therefore invalid for processing". 179 o Specifies the implementation of an ICV Message TLV, defined in 180 [RFC6622bis], using a SHA-256 based HMAC applied to the 181 appropriate message contents (and for HELLO messages also 182 including the IP datagram source address). Deployments of 183 [RFC6130] and [OLSRv2] using this framework should use an HMAC/ 184 SHA-256 ICV TLV, but may use different algorithms if more 185 appropriate in a deployment. An implementation may also use more 186 than one ICV TLV in a message, as long as they each use a 187 different algorithm to calculate the ICV. 189 o Specifies the implementation of a TIMESTAMP TLV, defined in 190 [RFC6622bis], to provide message replay protection. Deployments 191 of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX 192 time based timestamp, if the clocks in all routers in the network 193 can be synchronized with sufficient precision. 195 o Assumes that a router that is able to generate correct integrity 196 check values is considered trusted. 198 This framework does not: 200 o Specify which key identifiers are to be used in a MANET in which 201 the routers share more than one secret key. (Such keys will be 202 differentiated using the field defined in an ICV TLV in 203 [RFC6622bis].) 205 o Specify how to distribute cryptographic material (shared secret 206 key(s)). 208 o Specify how to detect compromised routers with valid keys. 210 o Specify how to handle (revoke) compromised routers with valid 211 keys. 213 4. Protocol Overview and Functioning 215 The framework specified in this document provides the following 216 functionalities for use with messages owned by [RFC6130] and 217 [OLSRv2]: 219 o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for 220 inclusion in an outgoing message. An implementation of [RFC6130] 221 and [OLSRv2] MAY use more than one ICV TLV in a message, even with 222 the same type extension, but these ICV TLVs MUST each use a 223 different algorithm to calculate the ICV, e.g., with different 224 hash and/or cryptographic functions when using type extension 1 or 225 2. An implementation of [RFC6130] and [OLSRv2] MUST at least be 226 able to generate an ICV TLV using HMAC/SHA-256 and one or more 227 secret keys shared by all routers. 229 o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis]) 230 for inclusion in an outgoing message. An implementation of 231 [RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message, 232 but not with the same type extension. An implementation of 233 [RFC6130] and [OLSRv2] that is able to synchronize the clocks in 234 all routers in the network with sufficient precision, MUST at 235 least be able to generate a TIMESTAMP TLV using POSIX time. 237 o Verification of ICV Message TLVs contained in a message, in order 238 to determine if this message MUST be rejected as "badly formed and 239 therefore invalid for processing" [RFC6130] [OLSRv2]. An 240 implementation of [RFC6130] and [OLSRv2] MUST at least be able to 241 verify an ICV TLV using HMAC/SHA-256 and one or more secret keys 242 shared by all routers. 244 o Verification of TIMESTAMP Message TLVs (as defined in 245 [RFC6622bis]) contained in a message, in order to determine if 246 this message MUST be rejected as "badly formed and therefore 247 invalid for processing" [RFC6130] [OLSRv2]. An implementation of 248 [RFC6130] and [OLSRv2] that is able to synchronize the clocks in 249 all routers in the network with sufficient precision, MUST at 250 least be able to verify a TIMESTAMP TLV using POSIX time. 252 ICV Packet TLVs (as defined in [RFC6622bis]) MAY be used by a 253 deployment of the multiplexing process defined in [RFC5444], either 254 as well as, or instead of, the protection of the NHDP and OLSRv2 255 messages. (Note that in the case of NHDP, the packet protection is 256 equally good, and also protects the packet header. In the case of 257 OLSRv2, the packet protection has different properties than the 258 message protection, especially for some forms of ICV. When packets 259 contain more than one message, the packet protection has lower 260 overheads in space and computation time.) 262 When a router generates a message on a MANET interface, this 263 framework: 265 o Specifies how to calculate an integrity check value for the 266 message. 268 o Specifies how to include that integrity check value using an ICV 269 Message TLV. 271 [RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to 272 processing by NHDP or OLSRv2. This framework specifies that a 273 message MUST be rejected if the ICV Message TLV is absent, or its 274 value cannot be verified. 276 5. Parameters 278 This following router parameters are specified for use by the two 279 protocols; the first is required only by NHDP, but may be visible to 280 OLSRv2, the second is required only by OLSRv2: 282 o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to 283 be validated may have. If the current POSIX time of the router 284 validating the HELLO message, minus the timestamp indicated in the 285 TIMESTAMP TLV of the HELLO message, is greater than 286 MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently 287 discarded. 289 o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be 290 validated may have. If the current POSIX time of the router 291 validating the TC message, minus the timestamp indicated in the 292 TIMESTAMP TLV of the TC message, is greater than 293 MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded. 295 The following constraints apply to these parameters: 297 o MAX_HELLO_TIMESTAMP_DIFF > 0 299 o MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL 300 o MAX_TC_TIMESTAMP_DIFF > 0 302 o MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME 304 The second and fourth of those constraints assume ideal time 305 synchronization of the clocks in all routers in the network. These 306 bounds MAY be relaxed to allow for expected timing differences 307 between routers (between neighboring routers for 308 MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in 309 the ideal case, the parameters SHOULD be significantly less than 310 those bounds. 312 6. Message Generation and Processing 314 This section specifies how messages are generated and processed by 315 [RFC6130] and [OLSRv2] when using this framework. 317 6.1. Message Content 319 Messages MUST have the content specified in [RFC6130] and [OLSRv2] 320 respectively. In addition, in order to conform to this framework, 321 each message MUST contain: 323 o At least one ICV Message TLV (as specified in [RFC6622bis]), 324 generated according to Section 6.2. Implementations of [RFC6130] 325 and [OLSRv2] MUST support the following version of the ICV TLV, 326 but other versions MAY be used instead, or in addition, in a 327 deployment, if more appropriate: 329 * For TC messages: 331 + type-extension := 1 333 * For HELLO messages: 335 + type-extension := 2 337 * hash-function := 3 (SHA-256) 339 * cryptographic-function := 3 (HMAC) 341 The ICV Value MAY be truncated as specified in [RFC6622bis]; the 342 selection of an appropriate length MAY be administratively 343 configured. A message MAY contain several ICV Message TLVs. 345 o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]), 346 generated according to Section 6.2. Implementations of [RFC6130] 347 and [OLSRv2] using this framework MUST support the following 348 version of the TIMESTAMP TLV, but other versions MAY be used 349 instead, or in addition, in a deployment, if more appropriate: 351 * type-extension := 1 353 6.2. Message Generation 355 After message generation (Section 11.1 of [RFC6130] and Section 16.1. 356 of [OLSRv2]) and before message transmission (Section 11.2 of 357 [RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs 358 specified in Section 6.1 MUST (unless already present) be added to an 359 outgoing message when using this framework. 361 The following processing steps (when using a single timestamp version 362 and a single ICV algorithm) MUST be performed for a cryptographic 363 algorithm that is used for generating an ICV for a message: 365 1. All ICV TLVs (if any) are temporarily removed from the message. 366 Any temporarily removed ICV TLVs MUST be stored, in order to be 367 reinserted into the message in step 5. The message size and 368 Message TLV Block size are updated accordingly. 370 2. and , if present, are temporarily 371 set to 0. 373 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to 374 the Message TLV Block. The message size and Message TLV block 375 size are updated accordingly. 377 4. A TLV of type ICV, as specified in Section 6.1, is added to the 378 Message TLV Block. The message size and Message TLV block size 379 are updated accordingly. 381 5. All ICV TLVs that were temporary removed in step 1, are restored. 382 The message size and Message TLV Block size are updated 383 accordingly. 385 6. and , if present, are restored to 386 their previous values. 388 An implementation MAY add either alternative TIMESTAMP and/or ICV 389 TLVs, or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs 390 MUST be inserted before adding ICV TLVs. 392 6.3. Message Processing 394 Both [RFC6130] and [OLSRv2] specify that: 396 "On receiving a ... message, a router MUST first check if the 397 message is invalid for processing by this router" 399 [RFC6130] and [OLSRv2] proceed to give a number of conditions that, 400 each, will lead to a rejection of the message as "badly formed and 401 therefore invalid for processing". When using a single timestamp 402 version, and a single ICV algorithm, the following conditions to that 403 list, each of which, if true, MUST cause NHDP or OLSRv2 (as 404 appropriate) to consider the message as invalid for processing when 405 using this framework: 407 1. The Message TLV Block of the message does not contain exactly one 408 TIMESTAMP TLV of the selected version. This version 409 specification includes the type extension. (The Message TLV 410 Block may also contain TIMESTAMP TLVs of other versions.) 412 2. The Message TLV block does not contain exactly one ICV TLV using 413 the selected algorithm and key identifier. This algorithm 414 specification includes the type extension, and for type 415 extensions 1 and 2, the hash function and cryptographic function. 416 (The Message TLV Block may also contain ICV TLVs using other 417 algorithms and key identifiers.) 419 3. Validation of the identified (in step 1) TIMESTAMP TLV in the 420 Message TLV block of the message fails, as according to 421 Section 6.3.1. 423 4. Validation of the identified (in step 2) ICV TLV in the Message 424 TLV block of the message fails, as according to Section 6.3.2. 426 An implementation MAY check the existence of, and verify, either 427 alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP 428 and/or ICV TLVs. 430 6.3.1. Validating a Message Based on Timestamp 432 For a TIMESTAMP Message TLV with type extension 1 (POSIX time) 433 identified as described in Section 6.2: 435 1. If the current POSIX time minus the value of that TIMESTAMP TLV 436 is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or 437 MAX_TC_TIMESTAMP_DIFF (for a TC message) then the message 438 validation fails. 440 2. Otherwise, the message validation succeeds. 442 If a deployment chooses to use a different type extension from 1, 443 appropriate measures MUST be taken to verify freshness of the 444 message. 446 6.3.2. Validating a Message Based on Integrity Check 448 For an ICV Message TLV identified as described in Section 6.2: 450 1. All ICV Message TLVs (including the identified ICV Message TLV) 451 are temporarily removed from the message, and the message size 452 and Message TLV block size are updated accordingly. 454 2. The message's and fields are 455 temporarily set to 0. 457 3. Calculate the integrity check value for the parameters specified 458 in the identified ICV Message TLV, as specified in [RFC6622bis]. 460 4. If this integrity check value differs from the value of 461 in the ICV Message TLV, then the message validation 462 fails. If the has been truncated (as specified in 463 [RFC6622bis], the integrity check value calculated in the 464 previous step MUST be truncated to the TLV length of the ICV 465 Message TLV before comparing it with the . 467 5. Otherwise, the message validation succeeds. The message's 468 and fields are restored to their 469 previous value, and the ICV Message TLVs are returned to the 470 message, whose size is updated accordingly. 472 7. Provisioning of Routers 474 Before a router is able to generate ICVs or validate messages, it 475 MUST acquire the shared secret key(s) to be used by all routers that 476 are to participate in the network. This specification does not 477 define how a router acquires secret keys. 479 8. IANA Considerations 481 This document has no actions for IANA. 483 9. Security Considerations 485 This document specifies a security framework for use with NHDP and 486 OLSRv2 that allows for alleviating several security threats. 488 9.1. Alleviated Attacks 490 This section briefly summarizes security threats that are alleviated 491 by the framework presented in this document. 493 9.1.1. Identity Spoofing 495 As only routers possessing the selected shared secret key are able to 496 add a valid ICV TLV to a message, identity spoofing is countered. 498 9.1.2. Link Spoofing 500 Link spoofing is countered by the framework specified in this 501 document, using the same argument as in Section 9.1.1. 503 9.1.3. Replay Attack 505 Replay attacks are partly countered by the framework specified in 506 this document, but this depends on synchronized clocks of all routers 507 in the MANET. An attacker that records messages to replay them later 508 can only do so in the selected time interval after the timestamp that 509 is contained in message. As an attacker cannot modify the content of 510 this timestamp (as it is protected by the identity check value), an 511 attacker cannot replay messages after this time. Within this time 512 interval it is still possible to perform replay attacks, however the 513 limits on the time interval are specified so that this will have a 514 limited effect on the operation of the protocol. 516 9.2. Limitations 518 If no synchronized clocks are available in the MANET, replay attacks 519 cannot be countered by the framework provided by this document. An 520 alternative version of the TIMESTAMP TLV defined in [RFC6622bis], 521 with a monotonic sequence number, may have some partial value in this 522 case, but will necessitate adding state to record observed message 523 sequence number information. 525 The framework provided by this document does not avoid or detect 526 security attacks by routers possessing the shared secret key that is 527 used to generate integrity check values for messages. 529 This framework relies on an out-of-band protocol or mechanism for 530 distributing the shared secret key(s) (and if an alternative 531 integrity check value is used, any additional cryptographic 532 parameters). 534 This framework does not provide a key revocation mechanism. 536 10. Acknowledgments 538 The authors would like to gratefully acknowledge the following 539 people: Henning Rogge (Frauenhofer FKIE). 541 11. Normative References 543 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 544 "The Optimized Link State Routing Protocol version 2", 545 work in progress draft-ietf-manet-olsrv2-19, March 2013. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 551 "Generalized MANET Packet/Message Format", RFC 5444, 552 February 2009. 554 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 555 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 556 RFC 6130, April 2011. 558 [RFC6622bis] 559 Herberg, U., Clausen, T., and C. Dearlove, "Integrity 560 Check Value and Timestamp TLV Definitions for Mobile Ad 561 Hoc Networks (MANETs)", work in 562 progress draft-ietf-manet-rfc6622-bis-02, April 2013. 564 Authors' Addresses 566 Ulrich Herberg 567 Fujitsu Laboratories of America 568 1240 E. Arques Ave. 569 Sunnyvale, CA, 94085, 570 USA 572 Email: ulrich@herberg.name 573 URI: http://www.herberg.name/ 574 Christopher Dearlove 575 BAE Systems Advanced Technology Centre 576 West Hanningfield Road 577 Great Baddow, Chelmsford 578 United Kingdom 580 Phone: +44 1245 242194 581 Email: chris.dearlove@baesystems.com 582 URI: http://www.baesystems.com/ 584 Thomas Heide Clausen 585 LIX, Ecole Polytechnique 586 91128 Palaiseau Cedex, 587 France 589 Phone: +33 6 6058 9349 590 Email: T.Clausen@computer.org 591 URI: http://www.thomasclausen.org/