Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Mar 2003 00:39:12 +0100

In your previous mail you wrote:

   A draft has been submitted to address source address selection at
   the per-socket (and per apps) basis. Currently it discusses preferences
   of source address selection by the application for privacy addresses,
   mobileipv6 addresses and Cryptographically generated addresses.
   Thus the application can reverse the sense of default source address
   selection by using the proposed APIs.
   
=> I have a major concern about the style of the API: it is at the
socket level ([gs]etsockopt()) when it should be in the context of
applications:
 - nobody wants to modify every applications in order to use the API
   (an unfortunately many applications can want to toggle one of the
    address selection knobs)
 - at the opposite a global knob is not flexible again.
What I propose is to put the policy in the context of applications
(Unix user structure, environment, etc, even monitors have this kind
of things) so one can tune the address selection before launching
applications. When the context can be managed from applications
(the usual case), this makes [gs]etsockopt() no more necessary.
And global flags can be replaced by default values...

Regards

[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Mar 2003 00:52:35 +0100

Some details:
   
       ..., CGA (cryptographically 
       generated addresses) and non-CGA addresses etc..
       
=> you should note that CGAs are covered by some IPRs.   
   
       It is recommended that the application does a getsockopt() prior

=> this comes only from the uncommon style (one flag from Home,
another one from Care-of, etc).         
   
       The following flags are added for the ai_flags in addrinfo data
       structure defined in Basic IPv6 Socket API Extension [2].
   
        AI_PREFER_SRC_HOME
        AI_PREFER_SRC_COA
        AI_PREFER_SRC_TMP
        AI_PREFER_SRC_PUBLIC
        AI_PREFER_SRC_CGA
        AI_PREFER_SRC_NONCGA
          
=> why _SRC_ ?
    
   5. IPv4-Mapped IPv6 Addresses
   
      IPv4-Mapped IPv6 addresses are not supported for setting preference
      on home, care-of-address, CGA, non-CGA, public or privacy auto-
      configured addresses as source addresses. Because they are all pure
      IPv6 addresses. 
   
=> this is not true for home/care-of and this section is not useful.
   
   6. Security Considerations
   
      It is also recommended that
      the applications set IPV6_V6ONLY IP level socket option to permit
      the nodes to not process IPv4 packets as IPv4 Mapped addresses.

=> I disagree about the implicit argument that IPv4 Mapped IPv6
addresses are unsafe. And BTW this has nothing to do in this document.   
   
   7. Open Issues
   
      - Are there more flags we should define at this point in time?
        For instance, PREFER_LARGEST_SCOPE?
   
=> all "matter of taste" rules of address selection which cannot be
controlled through the policy table should be covered here.

      - Is there a need for REQUIRE flags in addition to or instead of the
        PREFER flags?

=> yes, in some cases it is very important.

        Note that in general it isn't possible to verify 
        that a requirement can be satisfied until sendto() or connect()
        (when the destination address is known) thus this would result
        in late errors being reported to the application.
   
=> this is not really true because an application can use a connect()
to verify the selected source but as I am against any changes in
application I agree with the conclusion.

      - Is there a need for "validation" functions to go with these
        preferences such as functions that check whether an address is
        a temporary address?
   
=> it should be useful for some applications to have access to
status of addresses.

Thanks

   

   

   
   draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 7]
   
   INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003

   8. References
   
   Normative references:
   
   [1]    Richard Draves, "Default Address Selection for IPv6", 
              draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002.
     
   [2]    R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens,
              "Basic Socket Interface Extensions for IPv6", 
               draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002.
   
   Informative references:
   
   [3]    Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6"
              draft-ietf-mobileip-ipv6-20.txt, January, 2003.
   
   [4]    Deering, S., Hinden, R., "Internet Protocol, Version 6
              (IPv6), Specification", RFC 2460, Dec. 1998.
   
   [5]    Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced
              Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt  
              April 19, 2002.
   
   [6]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
          Address Autoconfiguration in IPv6", RFC 3041, January 2001.
   
   [7]    Montenegro, G. and C. Castelluccia, "Statistically Unique and
          Cryptographically Verifiable (SUCV) Identifiers and Addresses.", 
          NDSS 2002, February 2002.
   
   [8]    Castelluccia, C. and G. Montenegro, "Securing Group Management
          in IPv6 with  Cryptographically Generated  Addresses",
          draft-irtf-gsec-sgmv6-01 (work in progress), July 2002.

   9. Acknowledgements
   
      The authors like to thank members of mobile-ip and ipv6 working 
      groups for useful discussion on this topic. Richard Draves and
      Dave Thaler suggested that getaddrinfo also needs to be considered
      along with the new socket option. Gabriel Montenegro suggested that
      CGAs may also be considered in this document. Thanks to Alain Durand,
      Renee Danson, Alper Yegin and Francis Dupont for useful discussions.

   

   
   draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 8]
   
   INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003

   10.  Authors' Addresses

       Erik Nordmark
       Sun Microsystems Laboratories, Europe
       180 Avenue de l'Europe
       38334 Saint Ismier, France
       Email: [email-masked]

       Samita Chakrabarti
       Sun Microsystems, Inc. 
       4150 Network Circle 
       Santa Clara, CA 95054, USA
       Email: [email-masked]

       Julien Laganier 
       Sun Microsystems Laboratories, Europe
       180 Avenue de l'Europe
       38334 Saint Ismier, France
       Email: [email-masked]

   

   

   

   
   
   draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 9]
   
   
   --Clutter_of_Cats_249_000--

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Mar 2003 07:11:35 +0100 (CET)

> And global flags can be replaced by default values...

Having per-application or per-process overrides of anything if rife
with issues since an application isn't a single unit; it consists of
several independently developped pieces (libraries being the main source
of the many pieces). Thus while the developper know that the pieces s/he has
written want to turn the knob to affect the sockets in that piece
of code, making the knob be per-process means that it will also affect
sockets in libraries. Thus turning the per-process knob can have
unknown side effects.
Hence the need to have a per-socket knob.

  Erik

---

From: [email-masked]
Date: Sat, 22 Mar 2003 01:21:58 +0900

>>       structure defined in Basic IPv6 Socket API Extension [2].

	I don't understand how can flags to getaddrinfo(3) affect source
	address selection.  where does it take effect in the following code?

itojun

	error = getaddrinfo(host, serv, &hints, &res);
	s = -1;
	for (ai = res; ai; ai = ai->ai_next) {
		s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
		if (s < 0)
			continue;
		if (connect(s, ai->ai_addr, ai->ai_addrlen) < 0) {
			close(s);
			s = -1;
			continue;
		}
		break;
	}
	if (s < 0)
		exit(1);
	/* we have a socket */
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 22 Mar 2003 01:30:58 +0900

>getaddrinfo implementation itself?  of course, then libc would have to 
>aware of src addresses and such..

	getaddrinfo(3) does not open socket, so getaddrinfo(3) cannot perform
	[gs]etsockopt.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Mar 2003 18:28:34 +0200 (EET)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Mar 2003 17:52:19 +0100 (CET)

> => you should note that CGAs are covered by some IPRs.   

While I'm concerned about IPR and the IPR on CGA, I don't see
the benefit of cluttering every document and slide which contains
the string "CGA" with text about the IPR.
We seem to have been able to talk about RSA for a decade or more
without sprinkling text about IPR everywhere the string "RSA" appeared.
Is it a hard requirement from the WG that we do this?
  
> another one from Care-of, etc).         

Point taken. Others have commented on this as well.
  
>        structure defined in Basic IPv6 Socket API Extension [2].

To try to make it clearer that the application can't express this type
of preferences for the destination addresses.
    
> => this is not true for home/care-of and this section is not useful.

Agreed.
 
> addresses are unsafe. And BTW this has nothing to do in this document.   

Agreed.

> controlled through the policy table should be covered here.

Do you have a list handy?

> => yes, in some cases it is very important.

Any concerns about where and when the failures due to lack of
an address satisfying the REQUIREs?

> application I agree with the conclusion.

I don't understand what you are suggesting to change in the document
with respect to this.
Care to elaborate?

> => it should be useful for some applications to have access to

Ack.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Mar 2003 18:19:10 +0100

=> you have access to a per-socket knob when applications can locally
tune their context. IMHO to affect sockets in libraries is a good point.
For instance usually we'd like to use the local DNS but not always because
of views/two heads... What I propose should provide the maximal flexibility.

Thanks

PS: it can be implemented with a [gs]etsockopt() and some kind of
middleware. So our proposals are not really exclusive.
In the case of home/care-of address, my concern from the beginning
is that a knob is not enough, we need a smarter rule using the
proximity (i.e., prefix matching length) of addresses in order to
do the right choice. For instance usually with a destination in
a prefix of the visited link, a care-of is better than the home
address, and with a destination in the home site, the home address
is nearly always better.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Sebastien Roy <[email-masked]>
Date: Fri, 21 Mar 2003 12:33:19 -0500

> 	getaddrinfo(3) does not open socket, so getaddrinfo(3) cannot perform

This is how I understand the motivation behind these flags:

The destination address selection algorithm itself needs to compare each
destination with its chosen source address.  If the application has
input into the source address selection mechanism via the defined socket
options, then the application also needs to relay these source address
preferences to the destination address ordering algorithm so that it can
obtain accurate source address information for each destination.

If the destination ordering is implemented in the kernel, then
getaddrinfo() will need to pass the application's source address
preferences down with the list of destinations so that the algorithm can
accurately do its job.

It's still unclear to me if all of the newly defined AI_* flags are
really needed.  Do they each impact the ordering of the addresses in
cases that make a difference?  For example, there is no destination
address ordering rule that takes temporary source addresses into
account, so in what case would setting AI_PREFER_SRC_TMP change the
order of destinations?

-Seb

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Mar 2003 19:24:13 +0100

=> I understand now: you must make this crystal clear in the document!

   
=> it seems that someone should reread RFC 3484 very carefully.
I'll try to do it if I get enough free time...

   
=> EADDRNOTAVAIL on bind(), connect(), sendto(), etc. (i.e.,
all system calls which directly or indirectly assign a source address).

   
=> I disagree only about the rationale, so I propose to remove the statement
which begins by "Note".

Thanks

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 23 Mar 2003 19:13:43 +0900

>>>>> On Fri, 21 Mar 2003 00:39:12 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

>  - at the opposite a global knob is not flexible again.

I tend to agree, but do you have any concrete and feasible suggestion
to implement this?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Mar 2003 22:46:51 +0100

=> in an UNIX context, I can split the question into three parts:
where to put the information, how to manage it, how to use it.
For the place, there are two big options:
 - in user or proc structure, i.e., somewhere in the state of the process,
   exactly like user credentials with possible sharing, etc.
 - in environment variables, i.e., like RES_OPTIONS for tuning of
   the resolver library via the process context.
 In the second case, the obvious managing functions are [gs]etenv() but
this makes a textual form of tuning tables and knobs necessary.
 In the first case, the best is to add a sysctl() like you already did
for the policy table. An inheritance rule completes this part.
 There are two main ways to use the information: inside the kernel (like
the policy table or the proposed [gs]etsockopt()) or inside the standard
library (like the current resolver tuning).
 Try first with the policy table (because you have already a good support
for a global one and because it is the main way to tune address selection,
i.e., I already use it on some multi-homed nodes and there are some cases
where I'd like to have a per-application policy).

Thanks

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 27 Mar 2003 17:16:55 +0900

(In this reply, I'm very specific to the BSD kernel, which may not be
appropriate in this list.  If the discussion continues on this
particular topic, I'll change the place.)

>>>>> On Sun, 23 Mar 2003 22:46:51 +0100, 

   
> For the place, there are two big options:

Okay, and I'm mainly interested in the first two parts (particularly
the second one).

> where I'd like to have a per-application policy).

I've once considered similar approaches.  I didn't go further at that
time, because:

- a sysctl-like approach would require a big change in the kernel.
  We'd need to modify the proc structure and one/several files under
  the sys/kern directory.  I could not be sure if this kind of change
  was ever widely accepted for this particular purpose.

- using environment variables seemed a good approach in terms of the
  impact on the kernel internal code.  However, it is (possible but)
  not very easy to manipulate the env. variables within the kernel.
  I'd also like to avoid complicated string operations in the kernel.

					JINMEI, Tatuya