Re: Some comments on draft-tschofenig-v6ops-secure-tunnels

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

> On Wed, 9 Mar 2005, Mohan Parthasarathy wrote:
> > Thanks for your comments.
> 
> Likewise, thanks.  Your review and support is appreciated.
> 
> >> 2) section 2.2, IPsec will detect indirectly if the outer IPv4 addresses are wrong (spoofing among sites) because the
> >> decapsulation will fail since the crypto keys (for ESP and for AH) 
> >> are based on <remote IPv4 address,SPI>
> >
> > SPI alone is sufficient looking up the SA for unicast traffic and 
> > this is how it is defined in the recent AH/ESP drafts.
> 
> Hmm.  Does this cause any issues if this is implemented either way?  I 
> guess we'll need to support both..
> 
SPIs are generated by the receiver. The 2401bis-draft, AH and ESP drafts
specify that SPI alone is sufficient for inbound demultiplexing for unicast SAs.
But if the implementation does something different, it would not break anything.
Perhaps, we can mention this.

> >> 5) another use case scenario can be (and actually I've seen it 
> >> deployed): using this IPsec protected IPv6 tunnel as a back-up link 
> >> of a 'real native' IPv6 link in order to provide resiliency. This 
> >> of course requires routing protocols hence the use of the 
> >> 'transport mode' variant.
> >
> > I don't know whether it is relevant to the current document or not. 
> > I will let Pekka answer this.
> 
> (This is my opinion only, of course. :)
> 
> As far as I understand, the above is only an issue if the tunnel mode 
> SA is not modelled as an interface (based on the touch-vpn, now 
> RFC3884, right?  If it's an interface, it could be used to run a 
> routing protocol (as long as it's not IS-IS :-) just fine?
> 
> I think we are already assuming that it's an interface, and this 
> should not be an issue?
> 
I am not sure about this part. I have to read it again to see whether
we say this explicitly or not.

> In any case, section 5.1 already describes transport mode 
> router-to-router tunneling, which may or may not use lose ingress 
> filtering capability depending on whether the transport mode is 
> modelled as an interface or not.
> 
This is modeled as an interface because it is normally an IP-IP tunnel
+ IPsec.

> So, I guess we already have all the technical bases covered (unless 
> I'm missing something?), and the issue is just whether this usage 
> scenario is should be explicitly mentioned in the draft.  I'd say not, 
> because this seems to be a much more specific example case than the 
> ones we currently have in the draft, and listing a specific one might 
> be misleading.
> 
Agreed.

-mohan

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