Re: draft-gupta-ospf-ospfv3-auth-01.txt

[Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>]

Finally I think that this way to secure ospfv3 can be applied to other 
protocols that exchange both multicast and unicast packets. I mean that 
for example we can do the same for RIPng. Just need to replace OSPF 
protocol 89 with RIPng/UDP port 521.
The requirement is just on incoming path since destination address is 
ignored, use static keys, and as Itojun said, SPD aware of link-local 
scope. May be reserved SPI can be recommanded to facilate configuration.


Furthermore I beleive it works for NDP, as far as SPD selectors can 
permit it (e.g. protocol ICMPv6, type=neighbor solicit). But the 
scenario must support the assumption that hosts can share a key.

Regards,

Jean-Mickael

itojun@iijlab.net wrote:

>>Thanks for the correction. You are right. Word OSPF needs to be removed from
>>there. The new sentence should be
>>"In the incoming path, protocol, SPI and ingress interface ID MUST be used
>>to locate the SA to be applied."
>>where the protocol can be ESP or AH.
>>
> 
> 	is there any need for documenting it?  i mean, this is exactly
> 	the same as normal IPsec processing.  i think dropping the descrption
> 	and pointing people to ipsec document is the right thing to do.
> 	(the tricky thing is that you need to be aware of link-local scopes,
> 	which may be worth documenting)
> 
> itojun
> 
> 


-- 

Jean-Mickael GUERIN
Tel : +33 1 39 30 92 33
Web site : www.6wind.com