Re: New issue 17: Full connectivity

"Srinivasa Rao Addepalli" <[email protected]>
Newsgroups gmane.ietf.mobike
Organization Intoto Inc
Message-ID <1c9601c49467$edc94730$110fa8c0@SriniSony>
Umm... I guess it depends on how IPSec is implemented.

At the originitaing security gateway must know the remote peer IP address and uses
it as Destination IP address.

On the receiving end, some implementations would only check if the destination
IP address of the received packet is its local IP address. If so, it consumes the
packet and if not, the packet is forwarded. Some implementation might go beyond
this and might even look for exact match. 

MOBIKE might need to keep both kinds of implementation in mind or make 
explicit statement on the behaviour it expects from inbound processing.

Srini

Intoto Inc.
www.intoto.com
----- Original Message ----- 
From: "Francis Dupont" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Monday, September 06, 2004 12:00 PM
Subject: Re: [Mobike] New issue 17: Full connectivity 


> In your previous mail you wrote:
> 
>    >    Yes, certainly a node is likely to know better its own conditions
>    >    than the other node. But I don't quite understand the last point: 
>    >    in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel 
>    >    header) address at all? (unless they're multicast, but 
>    >    that's beyond IKEv2)
>    >    
>    > => tunnel inbound IPsec SAs have a local (destination) 
>    > end-point address. What I mean is the only way to fix this 
>    > address is to send a message to the other end saying what 
>    > address to use. BTW this is the central point of MOBIKE.
>    
>    Err, I'm a bit confused today... I cannot find anything in 2401bis
>    that would actually use the (outer) address in _inbound_ IPsec SAs 
>    for anything when processing unicast traffic.
> 
> => the destination address of packets sent over an IPsec tunnel SA is
> a mandatory parameter on the sending side, in this case the other peer.
> 
>    And if it's not used,
> 
> => it is used, here tunnel is not tunnel effect (:-).
> 
>    implementations don't even need to store it,
> 
> => it is stored. We can argue about the source address of the encapsulating
> header, but the destination address is a mandatory parameter.
> 
>    and MOBIKE does not need to update it, right?
> 
> => as this is something the local peer can't update without a signaling
> with the other peer, this is something which can only be managed with
> MOBIKE or a similar mechanism (in fact MOBIKE is the explicit mechanism,
> the other mechanism, the implicit one, is part of NAT traversal).
>    
>    Or am I missing something in 2401bis that actually uses it?
>    
> => we only misunderstand ourselved (:-).
> 
> Regards
> 
> [email protected]
>    
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.