Dirk said: "So what else is in existing RFCs that could be used (instead of the NAI options presented in the unauthenticated draft)?"
RFC 5113 Section 2.3 describes how domain-based routing typically functions in AAA networks, as well as the long-term problems with use of decorated NAIs. As noted there, NAI-routing depends on routing table entries maintained on proxy servers. While an NAI like "emergency" will be routed to the local AAA server, and "[email protected]" will be routed to the AAA server at example.com (assuming that this domain is reachable from the local network), the NAI "[email protected]" will result in routing to the AAA server maintained within the emergency.com domain (assuming that this domain was reachable from the local network). As noted below, emergency.com is a real domain, so this could result in a Denial of Service attack on the legitimate owner of that domain. Diverting unauthenticated emergency services calls to an existing domain that has not authorized use of its resources for that purpose is problematic to say the least. ; <<>> DiG 9.6.1-P3 <<>> @192.168.1.1 emergency.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8716 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;emergency.com. IN A ;; ANSWER SECTION: emergency.com. 3600 IN A 205.243.133.2 ;; Query time: 118 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Mar 22 10:56:32 2010 ;; MSG SIZE rcvd: 47 _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
