[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:2401bis Issue #68 -- VPNs with overlapping IP address ranges




Hi Steve,
         Since, there is one common method being followed (which does not 
require
         any interoperability), I am trying to see whether we should make 
this requirement as
         'Should' rather than 'MUST'.
    Thanks
    Ravi


At 11:03 AM 9/17/03 -0400, Stephen Kent wrote:
>At 12:08 +0530 9/17/03, Ravi Kumar wrote:
>>   Hi,
>>     Implementations (including ours) allocate one or more public IP 
>> addresses for each subscriber.
>>     It is expected that IKE negotiations and IPSEC traffic come with 
>> this(these) IP address(es) as
>>     'Destination IP'. Based on this, subscriber ID is extracted locally 
>> and after decryption, the packets
>>   are forwarded onto the subscriber network.
>>      It is not mandatory to negotiate Subscriber ID via IKE.
>>     Due to this, I feel, we should not make negotiation of subscribe ID 
>> mandatory.
>>    But, if same public IP address is used across multiple subscribers, 
>> then subscriber ID via IKE
>>    is needed. The proposed text should take care of above.
>>Thanks
>>  Ravi
>
>Ravi,
>
>Use of multiple public addresses, one per subscriber net per Ipsec 
>implementation, does provide another means of identifying the subscriber 
>net, but this requires an ability to acquire the multiple, public 
>addresses at each end. In that sense, this is a less general approach than 
>using a subscriber net ID internal to IPsec (IKE). In general I think we 
>are better off with a mechanism that works in all cases, vs. one that 
>works only if it is possible to acquire enough public addresses from an 
>ISP to assign one to each subscriber net address behind the device.
>
>Steve

The Views Presented in this mail are completely mine. The company is not 
responsible for what so ever.

----------
Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA

ROC HOME PAGE:
http://www.roc.co.in