On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen <[email protected]> wrote: > Hi Julien, > > > On 7/6/12 3:37 AM, Julien Laganier wrote: >> >> - 5203bis (registration) can IMHO be republished as is as I haven't >> seen any issue with the original version. If people agree I could >> republish it and we could WGLC it... > > > I posted some comments about 5203bis earlier this year but back then there > was no discussion regarding them. So, here goes again. > > Some of these have been discussed also earlier on this list (these relate to > requirements discovered with the native NAT traversal draft [1]), but I'll > have them all here for easier reference. > > Currently, the registrar has no way of indicating that it would otherwise > accept the registration, but it's currently running low on resources. For > this purpose, a failure type "Insufficient resources" could be added to the > "registration failure types". > > Registration using authentication with certificates could be part of the > registration RFC. Currently, only authentication with HI is defined, but > knowing all HIs beforehand is not practical in many cases. > > Text in section 3.2. of [1] could be used as a basis for this (just replace > "HIP' data relay" with "registrar"). Also, if this authentication mode is > added to the draft, failure type "Invalid certificate" should be added for > the failure case. > > Should we have these in the registration draft? > > [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal
I was going to shamelessly copy/paste section 3.2 of [1] in the registration draft but I noticed that [1] actually has a normative dependency on RFC 6253 "Host Identity Protocol Certificates" which is Experimental. Thus adding the support for certificates to a standard track HIP registration would cause a so-called downref which could be problematic... Gonzalo - what is your take on this? --julien _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
