Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi,

for some reason I didn't receive a message with comments from Gunter, but I noticed his comments at the ballot page
(it seems that the e-mail wasn't requested to be sent, as indicated in the datatracker).

I'm not sure if the message will be sent later and I want to respond to these comments, so I take the opportunity
to reply to the Mahesh's e-mail once again and comment on Gunter's comments :-)

First, thanks for these comments, I copy-pasted them from the datatracker. Plese, see inline.

> Document reviewed: draft-ietf-ipsecme-ikev2-auth-announce-09.txt
>
> Many thanks for this write-up. I see no issues from my side to progress this document.
> During my review cycle i noted some observations that you may consider if you find beneficial
>
> typos:
> s/overriden/overridden/

Fixed, thanks.

> [idnits] entries when runing idnits captured by shepherd review
>
> Review comments:
> 14	   supported authentication methods to their peers while establishing
> 15	   IKEv2 Security Association (SA).  This mechanism improves
>
> This draft is written for IKEv2, however would the proposed technology be used potentially by newer IKE flavors?
> (as networking generalist i am unclear about dynamics of IKE evolutions). If the IKEv2 is 'always' implicit 
> implied, then does it add value to mention IKEv2 here again? (i am ok with it either way, only questioning the extra characters in the abstract)

I agree that using both 'IKE' and 'IKEv2' adds some confusion for readers, but this is a long habit in IPsec.
To the point - this draft is written for IKEv2 (we don't know what IKEv3 would look like),
so it is always implicitly implied. Sometimes it is also stated explicitly.

> 84	   selecting authentication credentials.  The problem may arise when
> 85	   there are several credentials of different types configured on one
> 86	   peer, while only some of them are supported on the other peer.
>
> Not sure that saying "The problem" is accurate? there is added complexity or credential 
> inconsistency, but by itself that is not a problem.
>
> What about this rewrite suggestion to nail this down: 
>
> "SA establishment failure between peers may arise when there are several credentials of different types
> configured on one peer, while only some of them are supported on the other peer."

I used this text, thank you.

> 116	   When establishing IKE SA each party may send a list of authentication
> 117	   methods it supports and is configured to use to its peer.  For this
>
> Here is mentioning of IKE and not IKEv2. was this intentional. Is there a benefit in being consistent in terminology wrt IKE vs IKEv2?

As I said, there is a habit to mix 'IKE' and 'IKEv2' in IPsec world.

> 121	   the party sending it.  The sending party may additionally specify
> 122	   that some of the authentication methods are only for use with the
> 123	   particular trust anchors.  Upon receiving this information the peer
>
> what does 'the' in the above phrase "**the** particular trust anchors" refer towards? 
> (i am not so familiar with IKE so much, so am trying to understand how SUPPORTED_AUTH_METHODS is correlated, and trust anchors was not mentioned before. 
> (i do assume its well known terminology  though)

List of trust anchors are sent in the CERTREQ payload.
This extension allows to link each of the announced digital signature auth method with the particular
trust anchor (meaning that *this* algorithm should be used with *this* CA).

> 132	   message.  This notification contains a list of authentication methods
> 133	   supported by the responder, ordered by their preference.
>
> how is this correlating towards the trust anchor mentioned in above comment?

The order of preference is not correlated with the trust anchors.
The correlation is described above.

> 287	   announcements for these methods.  Implementations MUST ignore
> 288	   announcements which semantics they don't understand.
>
> s/which/with/

Changed to s/which/whose as Mahesh proposed.

> 390	4.  Interaction with IKE Extensions concerning Authentication
>
> is there a reason why IKE is mentioned instead of IKEv2 ?

Changed to 'IKEv2'.

Regards,
Valery.