idnits 2.17.1 draft-yegin-mip6-aaa-fwk-00.txt: -(98): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(142): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(293): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 465), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 118 has weird spacing: '...DIUS or ser...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2004) is 7192 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) -- Looks like a reference, but probably isn't: '8' on line 287 == Unused Reference: 'RFC2119' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 409, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-chowdhury-mip6-bootstrap-radius-00 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-01 == Outdated reference: A later version (-12) exists of draft-ietf-aaa-diameter-sip-app-03 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-auth-protocol-00 == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-00 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-mipv6-mib-03 == Outdated reference: A later version (-02) exists of draft-jang-dhc-haopt-00 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ��� 2 Network Working Group A. Yegin 3 Internet-Draft Samsung AIT 4 Expires: January 30, 2005 August 2004 6 AAA Mobile IPv6 Application Framework 7 draft-yegin-mip6-aaa-fwk-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 30, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes a framework for using AAA backend protocols 41 (e.g., RADIUS, Diameter) between home agents and AAA servers for 42 centralizing Mobile IPv6 service management. Implementation of this 43 framework requires definition of a new AAA application on the 44 aforementioned protocols. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. New AAA Application . . . . . . . . . . . . . . . . . . . . . 8 51 4. Relation to Mobile IPv6 Bootstrapping . . . . . . . . . . . . 9 52 5. Other Ways to Talk About Mobile IPv6 and AAA . . . . . . . . . 10 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 55 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 56 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 57 8.2 Informative References . . . . . . . . . . . . . . . . . . . 13 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 59 Intellectual Property and Copyright Statements . . . . . . . . 16 61 1. Introduction 63 AAA backend protocols, such as RADIUS [RFC2865] and Diameter 64 [RFC3588], enable centralized management of authentication, 65 authorization, and accounting (AAA) for a limited type of services 66 (Mobile IPv4 [I-D.ietf-aaa-diameter-mobileip], network access 67 [I-D.ietf-aaa-diameter-nasreq], SIP [I-D.ietf-aaa-diameter-sip-app]). 68 Currently there is no standard mechanism to centralize AAA for Mobile 69 IPv6 [RFC3775]" services. 71 The current Mobile IPv6 protocol design assumes pre-established 72 static configuration between a mobile node (MN, the client) and a 73 home agent (HA, the server) for authentication and authorization of 74 the mobility service. Although there are no standard protocols to 75 retrieve accounting information from a HA yet, SNMP will be useful in 76 the near future with the development of Mobile IPv6 MIBs 77 [I-D.ietf-mip6-mipv6-mib]. 79 The distributed AAA management model could be sufficient in the 80 presence of one static HA per MN, but this is not always the case. 81 In the presence of multiple HAs on a home subnet, reliance on 82 pre-configuration increases the network management overhead. 83 Additionally, there may be more than one home subnet that can be used 84 by a mobile node, in which case the number of possible HAs is further 85 increased. A central AAA infrastructure that is in charge of 86 authentication, authorization, and accounting for the Mobile IPv6 87 service between any MN and any HA in a domain would benefit 88 deployments by preventing AAA information replication and management 89 across the domain. 91 Furthermore, at times Mobile IPv6 service may have to cross operator 92 domain boundaries. For example, an (serving) operator may wish to 93 provide Mobile IPv6 service to another operator's customers for whom 94 it does not have any per-MN configuration in its local servers. A 95 scalable and secure Mobile IPv6 roaming service 96 [I-D.ietf-mip6-bootstrap-ps] cannot be made possible by solely 97 relying on the HA pre-configuration. The MN can only be 98 authenticated and authorized by an entity in its home operator���s 99 domain. The serving HA has to get in touch with the local AAA 100 infrastructure, which in turn must contact the AAA infrastructure of 101 the home operator. Upon successful authorization and delivery of the 102 service, associated accounting information can be delivered from the 103 serving operator to the home operator. 105 This document describes AAA Mobile IPv6 application framework that 106 enables AAA centralization and roaming for Mobile IPv6 services. 107 There is more than one way to use AAA technologies with Mobile IPv6. 108 The reader should note that the framework advocated in this document 109 constitutes only a subset of those possibilities. See Section 5 for 110 more on this subject. 112 2. Framework 114 The following figure depicts the interaction among various entities 115 using AAA for Mobile IPv6. 117 Mobile <---------------> Home agent/ <--------------> AAA 118 node Mobile IPv6, AAA client RADIUS or server 119 IKE Diameter 121 Figure 1: MIP6-AAA framework 123 In this framework, Mobile IPv6 protocol is executed between the MN 124 and the HA, as it normally would. Unlike a HA that relies on the 125 preconfigured information, the AAA-enabled HA (more precisely: AAA 126 client on HA) communicates with a AAA server in order to authenticate 127 and authorize the MN before starting the Mobile IPv6 service, and 128 later for making the accounting information available. 130 The current Mobile IPv6 design relies on use of IPsec for 131 authentication of protocol signaling between the MN and the HA. The 132 associated IPsec SA is created by running IKE [RFC3776] between the 133 two. The initial authentication and authorization of MN and HA 134 should be performed during the IKE execution. This is where HA must 135 consult the AAA infrastructure. The authorization at this stage is 136 for establishing an IPsec SA for Mobile IPv6 service. Authorization 137 parameters (e.g., max allowed lifetime) for the subsequent Mobile 138 IPv6 binding updates may also be delivered to the HA at this stage. 140 Upon successful IPsec SA establishment for Mobile IPv6 service, MN 141 can send binding updates to the HA. By the help of IPsec SA, the HA 142 can authenticate the MN without AAA server���s help. Furthermore, 143 the HA can also authorize the binding update if it already has the 144 authorization parameters from its earlier interaction with the AAA 145 server. Otherwise, the HA must contact the AAA server again to 146 perform binding update authorization. 148 Figure 2 is an illustration of a Mobile IPv6 session that starts with 149 IPsec SA establishment and includes one initial and one refreshing 150 binding updates. 152 MN HA AAA server 154 | | Auth/Authz for | 155 | IKE | MIPv6 IPsec SA | 156 |<------------------->|<-------------------->| 157 | | | 158 | Binding Update | Authz for BU | 159 |<------------------->|<-------------------->| 160 | | | 161 | | | 162 | | | 163 | Binding Update | Authz for BU | 164 |<------------------->|<-------------------->| 165 | | | 166 v 167 time 169 Figure 2: Message flow 171 Accounting-oriented HA-AAA interaction can take place any time MN is 172 authorized for the service, and it can be piggybacked with the 173 authentication/authorization messaging. 175 This framework is built upon following trust model. 177 (1) (2) 178 HA <------> AAA server <------> MN 179 ^ ^ 180 . . 181 ................................ 182 (3) 184 Figure 3: Trust model 186 It is assumed that HA-AAA (1) and MN-AAA (2) trust relations are 187 pre-configured. HA-AAA may have an indirect trust relation, that 188 spans multiple intermediate server and operator domains. MN-HA (3) 189 trust relation is dynamically created as a result of the AAA 190 interaction. MN can create trust relations with several HAs. These 191 trust relations should not outlive neither the MN-AAA nor the HA-AAA 192 trust relations. 194 An instance of this framework that relies on EAP-based authentication 195 is depicted in Figure 4. 197 Mobile <---------------> Home agent/ <--------------> AAA 198 node Mobile IPv6, AAA client EAP/RADIUS server 199 EAP/IKEv2 201 Figure 4: EAP-based IKE authentication 203 EAP [RFC3748] can provide end-to-end authentication between the MN 204 and AAA server. It can be used for IPsec SA authentication and 205 authorization by being transported on IKEv2 between the MN and HA, 206 and by a AAA-backend protocol between the HA and AAA. EAP framework 207 enables authentication between the peer (MN) and authentication 208 server (AAA server) via an authenticator (HA), and produces a 209 security association between the peer and the authenticator as a 210 result. While the produced security association is not an IPsec SA, 211 it can be used in building one. EAP is not used with Mobile IPv6 212 binding update authentication and authorization. 214 This framework can also be used with scenarios where other 215 authentication methods (non-EAP-based) are used with IKE. 216 Furthermore, future extensions to Mobile IPv6 specification may 217 involve IPsec/IKEless operation [I-D.ietf-mip6-auth-protocol]. They 218 should readily fit this framework as well. 220 [TBD: Consider using AAA with the CN as well. Now that alternatives 221 to RR-based BU security are being considered, and MN-CN pre-shared 222 key concept is around, leveraging AAA may come into the picture.] 224 3. New AAA Application 226 The architectural differences between Mobile IPv4 and Mobile IPv6 227 necessitate different AAA application framework for each. 229 Mobile IPv4 involves an intermediate server between the MN and the 230 HA, namely foreign agent (FA) which can be co-located with a network 231 access server (NAS). This impacts the end-to-end AAA flow. 233 The signaling authentication is built-in with the Mobile IPv4 234 protocol, whereas an additional protocol (IPsec) is used for Mobile 235 IPv6. Use of IPsec requires yet another protocol (IKE) for session 236 establishment. This nature of Mobile IPv6 leads to additional 237 authentication and authorization exchanges between the HA and AAA 238 server. The triggering event dictates the nature of exchange (e.g., 239 for authentication and authorization of a Mobile IP IPsec SA 240 creation, vs. authorization of a Mobile IPv6 binding update). In 241 Mobile IPv4, a single interaction between the serving agent (FA or 242 HA) and the AAA server is sufficient to accomplish authentication and 243 authorization of a registration request (equivalent of a Mobile IPv6 244 binding update). 246 The new AAA application is required to associate a given 247 authorization and accounting to the Mobile IPv6 service. When a AAA 248 client contacts a AAA server, it should be able to convey that the 249 request is for Mobile IPv6 service, as opposed to any other services 250 (network access, SIP, etc.). Additionally, service authorization 251 should take into account parameters like home address and binding 252 lifetime, which are specific to a Mobile IPv6 service. Finally, 253 accounting should support Mobile IPv6-specific MIBs 254 [I-D.ietf-mip6-mipv6-mib]. A formal list of requirements on this 255 interface must be worked out [TBD: future work]. 257 4. Relation to Mobile IPv6 Bootstrapping 259 Mobile IPv6 bootstrapping mechanisms [I-D.ietf-mip6-bootstrap-ps] are 260 potentially useful for providing three pieces of information to a MN: 261 HA address or home subnet prefix, home address, and a security 262 association between the MN and HA. The security association does not 263 have to be an IPsec SA, but something that helps creation of an IPsec 264 SA eventually. 266 Use of this framework assumes the MN already knows the HA address. 267 Hence an implementation of this framework cannot help with HA 268 discovery. 270 The security association between MN and HA can be created by using 271 the HA-AAA interface (see EAP-based example). 273 Home address can be obtained before or after running the AAA 274 protocol. For example, the home address may be known by the MN by 275 the time it engages in IKE or Mobile IPv6 with the HA, or it may be 276 dynamically assigned by the HA or the AAA server. An implementation 277 of the framework should work with any of these options. 279 Overall, this framework can be used as part of a Mobile IPv6 280 bootstrapping operation, but not necessarily as a complete solution 281 to that problem. 283 5. Other Ways to Talk About Mobile IPv6 and AAA 285 Talking about AAA does not make sense without specifying the 286 associated service. There is a difference between AAA for network 287 access and AAA for Mobile IPv6 services [8]. This distinction may be 288 blurry in certain cases (e.g., when Mobile IPv4 authentication is 289 used for network access as well), but otherwise they are at least 290 logically separate services. 292 There are several ways to mix the keywords �ǣMobile IPv6�ǥ with 293 �ǣAAA�ǥ in addition the one described in this document. They are 294 listed here for the sake of identification, but not necessarily for 295 advocating them. 297 (a) Using network access AAA to deliver Mobile IPv6 bootstrapping 298 information directly to a node (MN) 299 [I-D.giaretta-mip6-authorization-eap][I-D.le-aaa-mipv6-requirements] 300 [I-D.ohnishi-mip6-aaa-problem-statement]. 302 (b) Using network access AAA to deliver Mobile IPv6 bootstrapping 303 information to the network access server (NAS) 304 [I-D.chowdhury-mip6-bootstrap-radius]. It is assumed that the 305 information is delivered from NAS to the MN via some additional 306 protocol [I-D.jang-dhc-haopt] 308 (c) Piggybacking Mobile IPv6 signaling with network access AAA 309 [I-D.le-aaa-mipv6-requirements] This approach assumes that the AAA 310 servers for network access and Mobile IPv6 services are the same. 312 6. Security Considerations 314 The framework defined in this document is aligned with the AAA 315 backend protocols and the existing AAA applications. Therefore there 316 are no new security considerations stemming from the general 317 framework. 319 Details of the authorization are Mobile IPv6 specific. Exact 320 parameters, their semantics and processing details must be described 321 in an implementation of this framework. 323 7. Acknowledgements 325 Thanks to Kent Leung and Alpesh Patel for useful feedback. 327 8. References 329 8.1 Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 8.2 Informative References 336 [I-D.chowdhury-mip6-bootstrap-radius] 337 Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile 338 IPv6 bootstrapping", 339 draft-chowdhury-mip6-bootstrap-radius-00 (work in 340 progress), July 2004. 342 [I-D.giaretta-mip6-authorization-eap] 343 Giaretta, G., "MIPv6 Authorization and Configuration based 344 on EAP", draft-giaretta-mip6-authorization-eap-01 (work in 345 progress), July 2004. 347 [I-D.ietf-aaa-diameter-mobileip] 348 Calhoun, P., Johansson, T., Perkins, C. and T. Hiller, 349 "Diameter Mobile IPv4 Application", 350 draft-ietf-aaa-diameter-mobileip-20 (work in progress), 351 August 2004. 353 [I-D.ietf-aaa-diameter-nasreq] 354 Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 355 Network Access Server Application", 356 draft-ietf-aaa-diameter-nasreq-17 (work in progress), July 357 2004. 359 [I-D.ietf-aaa-diameter-sip-app] 360 Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 361 Canales-Valenzuela, C. and K. Tammi, "Diameter Session 362 Initiation Protocol (SIP) Application", 363 draft-ietf-aaa-diameter-sip-app-03 (work in progress), 364 July 2004. 366 [I-D.ietf-mip6-auth-protocol] 367 "Authentication Protocol for Mobile IPv6", 368 draft-ietf-mip6-auth-protocol-00 (work in progress), July 369 2004. 371 [I-D.ietf-mip6-bootstrap-ps] 372 Patel, A., "Problem Statement for bootstrapping Mobile 373 IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), 374 July 2004. 376 [I-D.ietf-mip6-mipv6-mib] 377 Keeni, G., Nagami, K., Koide, K. and S. Gundavelli, "A 378 Management Information Base for Mobile IPv6", 379 draft-ietf-mip6-mipv6-mib-03 (work in progress), July 380 2004. 382 [I-D.jang-dhc-haopt] 383 Yegin, A., "DHCP Option for Home Agent Discovery in 384 MIPv6", draft-jang-dhc-haopt-00 (work in progress), June 385 2004. 387 [I-D.le-aaa-mipv6-requirements] 388 Faccin, S., "Mobile IPv6 Authentication, Authorization, 389 and Accounting Requirements", 390 draft-le-aaa-mipv6-requirements-03 (work in progress), 391 February 2004. 393 [I-D.ohnishi-mip6-aaa-problem-statement] 394 Ohnishi, H., "Mobile IPv6 AAA Problem Statement", 395 draft-ohnishi-mip6-aaa-problem-statement-00 (work in 396 progress), February 2004. 398 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 399 "Remote Authentication Dial In User Service (RADIUS)", RFC 400 2865, June 2000. 402 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 403 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 405 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 406 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 407 3748, June 2004. 409 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 410 in IPv6", RFC 3775, June 2004. 412 [RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 413 Protect Mobile IPv6 Signaling Between Mobile Nodes and 414 Home Agents", RFC 3776, June 2004. 416 Author's Address 418 Alper E. Yegin 419 Samsung Advanced Institute of Technology 420 75 West Plumeria Drive 421 San Jose, CA 95134 422 USA 424 Phone: +1 408 544 5656 425 EMail: alper.yegin@samsung.com 427 Intellectual Property Statement 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed to 431 pertain to the implementation or use of the technology described in 432 this document or the extent to which any license under such rights 433 might or might not be available; nor does it represent that it has 434 made any independent effort to identify any such rights. Information 435 on the procedures with respect to rights in RFC documents can be 436 found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use of 441 such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository at 443 http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at 449 ietf-ipr@ietf.org. 451 Disclaimer of Validity 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 456 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 457 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 458 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Copyright Statement 463 Copyright (C) The Internet Society (2004). This document is subject 464 to the rights, licenses and restrictions contained in BCP 78, and 465 except as set forth therein, the authors retain all their rights. 467 Acknowledgment 469 Funding for the RFC Editor function is currently provided by the 470 Internet Society.