RE: [Seamoby] CAR DiscoveryProtocol Requirements...

["Qiang Zhang" <[e-mail]>]

Hi, 

This sounds more an IPsec issue. In reality, it does happen that a public IP needs to IKE to a private IP behind a perimeter gateway, the private IP is non-routable unless NAT mapping is performed. 

The solution for sake of saving headache can be to introduce additional tunneling beneath the IKE, such as UDP encapsulation.

2 SAs can probably achieve a similiar effect in a lot scenarios, but unfortunately it also somewhat defeats the peer2peer purpose for certain usages.

Sorry if am actually off topic...

Qiang


Be there RFC or not, this discussion is not based on the relevant issue in 
the first place. The issue raised is:

"can you make IKE create an SA between two nodes (one having a public 
address and another having a private address)?".

SA between public to private routers need not be done by direct IKE between 
public and private peers. In the case of public to private SA, SA can be 
created (say using IKE) between public router to border router of private 
router. Border router to private router SA can be taken for granted. There 
are various ways to do the latter including static configuration. Such a 
concatenation of two SAs will guarantee SA between public and private 
routers, which is what we want.

Hence, ability or otherwise of creating direct IKE between public and 
private is not at all the sumbling block behind the private address space 
requirement.

If there is any genuine stumbing block in this requirement, please let me 
know it.


Hemant


>From: Vijay Devarapalli <[e-mail]>
>To: "Hesham Soliman (ERA)" <[e-mail]>
>CC: [e-mail]
>Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
>Date: Fri, 11 Jan 2002 10:37:49 -0800
>
>"Hesham Soliman (ERA)" wrote:
> >
> > [reply for a very old mail]
> >
> >   > can you make IKE create an SA between two nodes (one having
> >   > a public address and another having a private address)?
> >
> > => Yes you can. There are IKE extensions for this.
>
>which RFC??
>
>---------------
>
>from Aboba's draft draft-ietf-ipsec-nat-reqts-00.txt
>
>c) Incompatibility between IKE address identifiers and NAT.
>    Where IP addresses are used as identifiers in IKE MM [7]
>    or QM, modification of the IP source or destination
>    addresses by NATs or reverse NATs will result in a
>    mismatch between the identifiers and the addresses in the
>    IP header. As described in [7], IKE implementations are
>    required to discard such packets.
>
>    In order to avoid use of IP addresses as IKE MM and QM identifiers,
>    userIDs and FQDNs can be used instead. Where user authentication
>    is desired, an ID type of ID_USER_FQDN can be used, as described in
>    [5]. Where machine authentication is desired, an ID type of ID_FQDN
>    can be used. In either case it is necessary to verify that the
>    proposed identity matches that enclosed in the certificate.
>    However, while use of USER_FQDN or FQDN identity types is possible
>    within IKE, there are usage scenarios (e.g. SPD entries
>    describing subnets) that cannot be accommodated this way.
>
>------------------
>
>However there are a couple of internet drafts in the IPSec WG
>dealing with this. Hopefully they will have a solution soon.
>
>If I am missing something, let me know.
>
>Vijay
>
>
> > I'm obviously not interested in anything involving
> > private addresses, but your point is incorrect.
> >
> > Hesham
>
>_______________________________________________
>Seamoby mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/seamoby


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby