idnits 2.17.1 draft-ietf-karp-isis-analysis-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2014) is 3516 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hartman-karp-mrkmp' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 505, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-yeung-g-ikev2-07 -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing Working Group U. Chunduri 2 Internet-Draft A. Tian 3 Intended status: Informational W. Lu 4 Expires: March 12, 2015 Ericsson Inc., 5 September 8, 2014 7 KARP IS-IS security analysis 8 draft-ietf-karp-isis-analysis-03 10 Abstract 12 This document analyzes the threats applicable for Intermediate system 13 to Intermediate system (IS-IS) routing protocol and security gaps 14 according to the KARP Design Guide. This document also provides 15 specific requirements to address the gaps with both manual and auto 16 key management protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 12, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.1. Sub network Independent . . . . . . . . . . . . . . . 4 58 2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 4 59 2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5 61 2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5 62 2.3.1.1. Current Recovery mechanism for LSPs . . . . . . . 6 63 2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7 64 2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8 65 3. Gap Analysis and Security Requirements . . . . . . . . . . . 8 66 3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8 67 3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 This document analyzes the current state of Intermediate system to 79 Intermediate system (IS-IS) protocol according to the requirements 80 set forth in [RFC6518] for both manual and auto key management 81 protocols. 83 With currently published work, IS-IS meets some of the requirements 84 expected from a manually keyed routing protocol. Integrity 85 protection is expanded with more cryptographic algorithms and also 86 limited algorithm agility (HMAC-SHA family) is provided with 87 [RFC5310]. Basic form of Intra-connection re-keying capability is 88 provided by the specification [RFC5310] with some gaps as explained 89 in Section 3. 91 This draft summarizes the current state of cryptographic key usage in 92 IS-IS protocol and several previous efforts to analyze IS-IS 93 security. This includes base IS-IS specification [RFC1195], 94 [RFC5304], [RFC5310] and the OPSEC working group document [RFC6039]. 96 Authors would like to acknowledge all the previous work done in the 97 above documents. 99 This document also analyzes applicability of various threats as 100 described in [RFC6862] to IS-IS, lists gaps and provide specific 101 recommendations to thwart the applicable threats for both manual 102 keying and for auto key management mechanisms. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 1.2. Acronyms 112 DoS - Denial of Service. 114 IGP - Interior Gateway Protocol. 116 IIH - IS-IS HELLO PDU. 118 IPv4 - Internet Protocol version 4. 120 KMP - Key Management Protocol (auto key management). 122 LSP - IS-IS Link State PDU. 124 MKM - Manual Key management Protocols. 126 NONCE - Number Once. 128 SA - Security Association. 130 SNP - Sequence number PDU. 132 2. Current State 134 IS-IS is specified in International Standards Organization (ISO) 135 10589, with extensions to support Internet Protocol version 4 (IPv4) 136 described in [RFC1195]. The specification includes an authentication 137 mechanism that allows for any authentication algorithm and also 138 specifies the algorithm for clear text passwords. Further [RFC5304] 139 extends the authentication mechanism to work with HMAC-MD5 and also 140 modifies the base protocol for more effectiveness. [RFC5310] 141 provides algorithm agility, with new generic crypto authentication 142 mechanism (CRYPTO_AUTH) for IS-IS. The CRYPTO_AUTH also introduces 143 Key ID mechanism that map to unique IS-IS Security Associations 144 (SAs). 146 The following sections describe the current authentication key usage 147 for various IS-IS messages, current key change methodologies and the 148 various potential security threats. 150 2.1. Key Usage 152 IS-IS can be provisioned with a per interface, peer-to-peer key for 153 IS-IS HELLO PDUs (IIH) and a group key for Link State PDUs (LSPs) and 154 Sequence number PDUs (SNPs). If provisioned, IIH packets potentially 155 can use the same group key used for LSPs and SNPs. 157 2.1.1. Sub network Independent 159 Link State PDUs, Complete and partial Sequence Number PDUs come under 160 Sub network Independent messages. For protecting Level-1 SNPs and 161 Level-1 LSPs, provisioned Area Authentication key is used. Level-2 162 SNPs as well as Level-2 LSPs use the provisioned domain 163 authentication key. 165 Since authentication is performed on the LSPs transmitted by an IS, 166 rather than on the LSP packets transmitted to a specific neighbor, it 167 is implied that all the ISes within a single flooding domain must be 168 configured with the same key in order for authentication to work 169 correctly. This is also true for SNP packets, though they are 170 limited to link local scope in broadcast networks. 172 If multiple instances share the circuits as specified in [RFC6822], 173 instance specific authentication credentials can be used to protect 174 the LSPs and SNPs with in an area or domain. It is important to 175 note, [RFC6822] also allows usage of topology specific authentication 176 credentials with in an instance for the LSPs and SNPs. 178 2.1.2. Sub network dependent 180 IS-IS HELLO PDUs use the Link Level Authentication key, which may be 181 different from that of LSPs and SNPs. This could be particularly 182 true for point-to-point links. In broadcast networks it is possible 183 to provision the same common key used for LSPs and SNPs, to protect 184 IIH messages. This allows neighbor discovery and adjacency formation 185 with more than one neighbor on the same physical interface. If 186 multiple instances share the circuits as specified in [RFC6822], 187 instance specific authentication credentials can be used to protect 188 Hello messages. 190 2.2. Key Agility 192 Key roll over without effecting the routing protocols operation in 193 general and IS-IS in particular, is necessary for effective key 194 management protocol integration. 196 Current HMAC-MD5 crypto authentication as defined in [RFC5304], 197 suggests a transition mode, so that ISes use a set of keys when 198 verifying the authentication value, to allow key changes. This 199 approach will allow changing the authentication key manually without 200 bringing down the adjacency and without dropping any control packet. 201 But, this can increase the load on control plane for the key 202 transition duration as each control packet may have to be verified by 203 more than one key and also allows to mount a potential Denial of 204 Service (DoS) attack in the transition duration. 206 The above situation is improved with the introduction of Key ID 207 mechanism as defined in [RFC5310]. With this, the receiver 208 determines the active security association (SA) by looking at the Key 209 ID field in the incoming PDU and need not try with other keys, when 210 the integrity check or digest verification fails. But, neither Key 211 co-ordination across the group nor exact key change mechanism is 212 clearly defined. [RFC5310] says: " Normally, an implementation would 213 allow the network operator to configure a set of keys in a key chain, 214 with each key in the chain having a fixed lifetime. The actual 215 operation of these mechanisms is outside the scope of this document." 217 2.3. Security Issues 219 The following section analyzes various security threats possible, in 220 the current state for IS-IS protocol. 222 2.3.1. Replay Attacks 224 Replaying a captured protocol packet to cause damage is a common 225 threat for any protocol. Securing the packet with cryptographic 226 authentication information alone cannot mitigate this threat 227 completely. Though this problem is more prevalent in broadcast 228 networks it is important to note, most of the IGP deployments use 229 P2P-over-lan [RFC5309], which makes an adversary replay 'easier' than 230 the traditional P2P networks 232 In intra-session replay attacks a secured protocol packet of the 233 current session is replayed, can cause damage, if there is no other 234 mechanism to confirm this is a replay packet. In inter-session 235 replay attacks, captured packet from one of the previous session can 236 be replayed to cause the damage. IS-IS packets are vulnerable to 237 both these attacks, as there is no sequence number verification for 238 IIH packets and SNP packets. Also with current manual key management 239 periodic key changes across the group are done rarely. Thus the 240 intra-connection and inter-connection replay requirements are not 241 met. 243 IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 244 family in [RFC5310], to protect IS-IS packets. An adversary could 245 replay old IIHs or replay old SNPs that would cause churn in the 246 network or bring down the adjacencies. 248 1. At the time of adjacency bring up an IS sends IIH packet with 249 empty neighbor list (TLV 6) and with the authentication 250 information as per provisioned authentication mechanism. If this 251 packet is replayed later on the broadcast network, all ISes in 252 the broadcast network can bounce the adjacency to create a huge 253 churn in the network. 255 2. Today LSPs have intra-session replay protection as LSP header 256 contains 32-bit sequence number which is verified for every 257 received packet against the local LSP database. But, if a node 258 in the network is out of service (is undergoing some sort of high 259 availability condition, or an upgrade) for more than LSP refresh 260 time and the rest of the network ages out the LSPs of the node 261 under consideration, an adversary can potentially plunge in 262 inter-session replay attacks in the network. If the key is not 263 changed in the above circumstances, attack can be launched by 264 replaying an old LSP with higher sequence number and fewer 265 prefixes or fewer adjacencies. This may force the receiver to 266 accept and remove the routes from the routing table, which 267 eventually causes traffic disruption to those prefixes. However, 268 as per the IS-IS specification there is a built-in recovery 269 mechanism for LSPs from inter-session replay attacks and it is 270 further discussed in Section 2.3.1.1. 272 3. In any IS-IS network (broadcast or otherwise), if an old and an 273 empty Complete Sequence Number packet (CSNP) is replayed this can 274 cause LSP flood in the network. Similarly a replayed Partial 275 Sequence Number packet (PSNP) can cause LSP flood in the 276 broadcast network. 278 2.3.1.1. Current Recovery mechanism for LSPs 280 In the event of inter-session replay attack by an adversary, as LSP 281 with higher sequence number gets accepted, it also gets propagated 282 until it reaches the originating node of the LSP. The originator 283 recognizes the LSP is "newer" than in the local database and this 284 prompts the originator to flood a newer version of the LSP with 285 higher sequence number than the received. This newer version can 286 potentially replace any versions of the replayed LSP which may exist 287 in the network. 289 But in the above process, depending on where in the network the 290 replay is initiated, how quick the nodes in the network react to the 291 replayed LSP and also how different the content in the accepted LSP 292 determines the damage caused by the replayed LSP. 294 2.3.2. Spoofing Attacks 296 IS-IS shares the same key between all neighbors in an area or in a 297 domain to protect the LSP, SNP packets and in broadcast networks even 298 IIH packets. False advertisement by a router is not within scope of 299 the KARP work. However, given the wide sharing of keys as described 300 above, there is a significant risk that an attacker can compromise a 301 key from one device, and use it to falsely participate in the 302 routing, possibly even in a very separate part of the network. 304 If the same underlying topology is shared across multiple instances 305 to transport routing/application information as defined in [RFC6822], 306 it is necessary to use different authentication credentials for 307 different instances. In this connection, based on the deployment 308 considerations, if certain topologies in a particular IS-IS instance 309 require more protection from spoofing attacks and less exposure, 310 topology specific authentication credentials can be used for LSPs and 311 SNPs as facilitated in [RFC6822]. 313 Currently possession of the key itself is used as authentication 314 check and there is no identity check done separately. Spoofing 315 occurs when an illegitimate device assumes the identity of a 316 legitimate one. An attacker can use spoofing as a means for 317 launching various types of attacks. For example: 319 1. The attacker can send out unrealistic routing information that 320 might cause the disruption of network services such as block 321 holes. 323 2. A rogue system having access to the common key used to protect 324 the LSP, can send an LSP, setting the Remaining Lifetime field to 325 zero, and flooding it thereby initiating a purge. Subsequently, 326 this also can cause the sequence number of all the LSPs to 327 increase quickly to max out the sequence number space, which can 328 cause an IS to shut down for MaxAge + ZeroAgeLifetime period to 329 allow the old LSPs to age out in other ISes of the same flooding 330 domain. 332 2.3.3. DoS Attacks 334 Denial-of-service (DoS) attacks using the authentication mechanism is 335 possible and an attacker can send packets which can overwhelm the 336 security mechanism itself. An example is initiating an overwhelming 337 load of spoofed but integrity protected protocol packets, so that the 338 receiver needs to process the integrity check, only to discard the 339 packet. This can cause significant CPU usage. DoS attacks are not 340 generally preventable with in the routing protocol. As the attackers 341 are often remote, the DoS attacks are more damaging to area-scoped or 342 domain-scoped packet receivers than link-local scoped packet 343 receivers. 345 3. Gap Analysis and Security Requirements 347 This section outlines the differences between the current state of 348 the IS-IS routing protocol and the desired state as specified in KARP 349 Design Guidelines [RFC6518]. The section focuses on where IS-IS 350 protocol fails to meet general requirements as specified in the 351 threats and requirements document. 353 This section also describes security requirements that should be met 354 by IS-IS implementations that are secured by manual as well as auto 355 key management protocols. 357 3.1. Manual Key Management 359 1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be 360 protected with HMAC-SHA family of cryptographic algorithms. The 361 specification provides the limited algorithm agility (SHA 362 family). By using Key IDs, it also conceals the algorithm 363 information from the protected control messages. 365 2. Even though both intra and inter session replay attacks are best 366 prevented by deploying key management protocols with frequent key 367 change capability, basic constructs for sequence number should be 368 there in the protocol messages. So, some basic or extended 369 sequence number mechanism should be in place to protect IIH 370 packets and SNP packets. The sequence number should be increased 371 for each protocol packet. This allows mitigation of some of the 372 replay threats as mentioned in Section 2.3.1. 374 3. Any common key mechanism with keys shared across a group of 375 routers is susceptible to spoofing attacks caused by a malicious 376 router. Separate authentication check (apart from the integrity 377 check to verify the digest) with digital signatures as described 378 in [RFC2154], can effectively nullify this attack. But this 379 approach was never deployed and one can only assume due to 380 operational considerations at that time. The alternative 381 approach to thwart this threat would be by using the keys from 382 the group key management protocol. As the group key(s) are 383 generated by authenticating the member ISes in the group first, 384 and then periodically rekeyed, per packet identity or 385 authentication check may not be needed. 387 4. In general DoS attacks may not be preventable with mechanism from 388 routing protocols itself. But some form of Admin controlled 389 lists (ACLs) at the forwarding plane can reduce the damage. 390 There are some other forms the DoS attacks common to any protocol 391 are not in scope as per the section 3.3 in [RFC6862]. 393 As discussed in Section 2.2, though Key ID mechanism in [RFC5310] 394 helps, better key co-ordination mechanism for key roll over is 395 desirable even with manual key management. But, it fell short of 396 specifying exact mechanism other than using key chains. The specific 397 requirements: 399 a. Keys SHOULD be able to change without affecting the established 400 adjacency and even better without any control packet loss. 402 b. Keys SHOULD be able to change without effecting the protocol 403 operations, for example, LSP flooding should not be held for a 404 specific Key ID availability. 406 c. Any proposed mechanism SHOULD also be further incrementally 407 deployable with key management protocols. 409 3.2. Key Management Protocols 411 In broadcast deployments, the keys used for protecting IS-IS 412 protocols messages can, in particular, be group keys. A mechanism, 413 similar to as described in [I-D.weis-gdoi-mac-tek] can be used to 414 distribute group keys to a group of ISes in Level-1 area or Level-2 415 domain, using GDOI as specified in [RFC6407]. There are also similar 416 approaches with IKEv2 based group key management solutions, to 417 routing protocols as described in [I-D.yeung-g-ikev2] and [I- 418 D.hartman-karp-mrkmp]. 420 If a group key is used, the authentication granularity becomes group 421 membership of devices, not peer authentication between devices. 422 Group key management protocol deployed SHOULD be capable of 423 supporting rekeying support. 425 In some deployments, where IS-IS point-to-point (P2P) mode is used 426 for adjacency bring-up, sub network dependent messages (IIHs) can use 427 a different key shared between the two point-to-point peers, while 428 all other messages use a group key. When group keying mechanism is 429 deployed, even the P2P IIHs can be protected with the common group 430 keys. This approach facilitates one key management mechanism instead 431 of both pair-wise keying and group keying protocols to be deployed 432 together. If same circuits are shared across multiple instances, the 433 granularity of the group can become per instance for IIHs and per 434 instance/topology for LSPs and SNPs as specified in the [RFC6822]. 436 Effective key change capability with in the routing protocol which 437 allows key roll over without impacting the routing protocol 438 operation, is one of the requirements for deploying any group key 439 mechanism. Once such mechanism is in place with deployment of group 440 key management protocol, IS-IS can be protected from various threats 441 not limited to intra and inter session replay attacks and spoofing 442 attacks. 444 Specific use of crypto tables [RFC7210] should be defined for IS-IS 445 protocol. 447 4. IANA Considerations 449 This document defines no new namespaces. 451 5. Security Considerations 453 This document is mostly about security considerations of IS-IS 454 protocol, lists potential threats and security requirements for 455 solving those threats. This document does not introduce any new 456 security threats for IS-IS protocol. For more detailed security 457 considerations please refer the Security Considerations section of 458 the KARP Design Guide [RFC6518] document as well as KARP threat 459 document [RFC6862]. 461 6. Acknowledgements 463 Authors would like to thank Joel Halpern for initial discussions on 464 this document and giving valuable review comments. Authors would 465 like to acknowledge Naiming Shen for reviewing and providing feedback 466 on this document. 468 7. References 470 7.1. Normative References 472 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 473 dual environments", RFC 1195, December 1990. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 479 Authentication", RFC 5304, October 2008. 481 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 482 and M. Fanto, "IS-IS Generic Cryptographic 483 Authentication", RFC 5310, February 2009. 485 7.2. Informative References 487 [I-D.hartman-karp-mrkmp] 488 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 489 Key Management Protocol (MaRK)", draft-hartman-karp- 490 mrkmp-05 (work in progress), September 2012. 492 [I-D.weis-gdoi-mac-tek] 493 Weis, B. and S. Rowles, "GDOI Generic Message 494 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 495 (work in progress), September 2011. 497 [I-D.yeung-g-ikev2] 498 Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 499 Management using IKEv2", draft-yeung-g-ikev2-07 (work in 500 progress), November 2013. 502 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 503 Digital Signatures", RFC 2154, June 1997. 505 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 506 Key Management", BCP 107, RFC 4107, June 2005. 508 [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN 509 in Link State Routing Protocols", RFC 5309, October 2008. 511 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 512 with Existing Cryptographic Protection Methods for Routing 513 Protocols", RFC 6039, October 2010. 515 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 516 of Interpretation", RFC 6407, October 2011. 518 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 519 Routing Protocols (KARP) Design Guidelines", RFC 6518, 520 February 2012. 522 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 523 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 525 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 526 Authentication for Routing Protocols (KARP) Overview, 527 Threats, and Requirements", RFC 6862, March 2013. 529 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 530 "Database of Long-Lived Symmetric Cryptographic Keys", RFC 531 7210, April 2014. 533 Authors' Addresses 535 Uma Chunduri 536 Ericsson Inc., 537 300 Holger Way, 538 San Jose, California 95134 539 USA 541 Phone: 408 750-5678 542 Email: uma.chunduri@ericsson.com 544 Albert Tian 545 Ericsson Inc., 546 300 Holger Way, 547 San Jose, California 95134 548 USA 550 Phone: 408 750-5210 551 Email: albert.tian@ericsson.com 553 Wenhu Lu 554 Ericsson Inc., 555 300 Holger Way, 556 San Jose, California 95134 557 USA 559 Email: wenhu.lu@ericsson.com