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

From: "Bound, Jim" <[email-masked]>
Date: Mon, 24 Mar 2003 01:14:01 -0500

Erik,

On CGA.  It is different now.  We face mass deployment of required
security worldwide and I hear it all the time now.  CGA being a base for
our addresses is far different scope of use than RSA mumbo-jumbo et al.
The IPR is a real problem and I think a show stopper. There can be no
vendor advantage over others with CGA if it is to become pervasive, and
questionable for the IETF to pursue this to far without getting some
type of resolution.  The IETF could be setting a precedent and opening
pandora's box and end up sitting in anti-trust problem. Go talk to your
IETF ISOC council is my advise if you have not already.  It is also not
the same type of legal problem as using RSA as an entity.

I think labeling it often as IPR issue is prudent in our community.
Including not using it because of the IPR.

/jim

>-----Original Message-----
>From: Erik Nordmark [mailto:[email-masked]] 
>Sent: Friday, March 21, 2003 11:52 AM
>To: Francis Dupont
>Cc: Samita Chakrabarti; [email-masked]; 
>[email-masked]; [email-masked]; [email-masked]
>Subject: Re: [mobile-ip] Draft on IPv6 source address 
>selection socket API 
>
>
>> Some details:
>>    
>>        ..., CGA (cryptographically 
>>        generated addresses) and non-CGA addresses etc..
>>        
>> => 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?
>  
>>        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).         
>
>Point taken. Others have commented on this as well.
>  
>>        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_ ?
>
>To try to make it clearer that the application can't express 
>this type of preferences for the destination addresses.
>    
>>    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.
>
>Agreed.
> 
>>    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.   
>
>Agreed.
>
>>    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.
>
>Do you have a list handy?
>
>>       - Is there a need for REQUIRE flags in addition to or 
>instead of the
>>         PREFER flags?
>> 
>> => 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?
>
>>         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.
>
>I don't understand what you are suggesting to change in the 
>document with respect to this. Care to elaborate?
>
>>       - 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.
>
>Ack.
>
>  Erik
>
>
>--------------------------------------------------------------------
>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]
>--------------------------------------------------------------------
>

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2003 12:10:09 +0100 (CET)

> On CGA.  It is different now.  We face mass deployment of required security
> worldwide and I hear it all the time now.  CGA being a base for our
> addresses is far different scope of use than RSA mumbo-jumbo et al.  The IPR
> is a real problem and I think a show stopper. There can be no vendor
> advantage over others with CGA if it is to become pervasive, and
> questionable for the IETF to pursue this to far without getting some type of
> resolution.  The IETF could be setting a precedent and opening pandora's box
> and end up sitting in anti-trust problem. Go talk to your IETF ISOC council
> is my advise if you have not already.  It is also not the same type of legal
> problem as using RSA as an entity.
> 

I agree with the IPR concerns for CGA.
It just feels like overkill to have to attach a "there is IPR" piece of
text every time we mention CGA in documents.
The documents that specify to how implement CGA (the stuff that is
actually covered by the claimed IPR) should have the required notices for sure,
but I'm a bit leery of putting it everywhere where CGA is referenced. My
concern is that should the IPR situation for CGA change we'll have a dozen
documents which potentially contain inaccurate information. But perhaps this
isn't a big deal.

  Erik