RE: [Hipsec] Base draft & ESP draft: snapshots

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] 
> Sent: Thursday, August 18, 2005 6:12 AM
> To: Petri Jokela
> Cc: hipsec@ietf.org
> Subject: Re: [Hipsec] Base draft & ESP draft: snapshots
> 
> >> There appears to be a minor problem between 6.13 and 6.14. 
>  6.13 says 
> >> that CLOSE may be answered with an ICMP, 6.14 that they 
> are dropped.
> >>
> >
> > Actually, there is a whole section "5.4.4  Non-existing HIP 
> > Association"
> > that discusses about responding to CLOSE and NOTIFY 
> messages with an 
> > ICMP if we do not have any state with that peer. In Paris, 
> I think we 
> > agreed that we are not going to respond to an incoming 
> CLOSE with any 
> > message. Should we ignore also incoming NOTIFYs if there is no 
> > association? Is there any reason why we would like to answer to 
> > NOTIFYs in UNASSOCIATED state?
> 
> Good question.  I don't have any strong opinion; I'm just 
> worried about us not being consistent.
> 

I would suggest not responding to NOTIFY (i.e., no change to current
text).

As for 6.14, I think it should be aligned to 5.4.4 which is the newer
text on this matter.

> >> Need to specify "LSI" briefly in Section 2 as it is used in 6.1
> >>
> >
> > Should we remove all text related to LSIs, and concentrate only on 
> > HITs in this draft? All LSI related stuff would be in 
> > draft-henderson-hip-applications.
> 
> Either way works for me.  I'd slightly prefer rewriting 6.1. and
> 6.2 so that they don't refer to LSIs as all, because IMHO those
> two sections should be completely rewritten anyway.   They are
> currently crumby, as a remaining issue resulting from the 
> document split.

I think we need some section in this document that at least hints at how
one might map from applications (and application-level names for hosts)
to host identities, even if it mostly points to a separate document.
Note that the document it is pointing to is not in the current WG
charter to develop, but has instead been sent to the RG based on
Minneapolis meeting discussions.

I actually don't have a problem with how 6.1 and 6.2 are currently
written, except that they don't really allow for some of the
opportunistic HIP scenarios (e.g., HIT in TCP option) that have been
recently discussed (in which case, the address used by the application
may really be an IP address and not an LSI or HIT).  This part of HIP
implementation will likely be quite different from implementation to
implementation, so it seems best to keep it as a loose sketch of how
processing might be done.

Tom

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec