Subject: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 27 Feb 2015 12:05:51 -0500

Hello,

Thank you very much to the authors and WG for your efforts on this draft!
It's good to see some of the OS work coming through as options in protocols.

I just have a couple of comments/questions to clarify before we progress
this into IETF last call.

The introduction is very well written, thank you for that.

Section 2.4
I see that this draft does not update RFC4301, but in reading this section,
should it?

-- 

Best regards,
Kathleen

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Feb 2015 11:55:21 -0800

On Feb 27, 2015, at 9:05 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello,
> 
> Thank you very much to the authors and WG for your efforts on this draft!  It's good to see some of the OS work coming through as options in protocols.
> 
> I just have a couple of comments/questions to clarify before we progress this into IETF last call.
> 
> I see that this draft does not update RFC4301, but in reading this section, should it?

That's a good question, and you can see it both ways.

- The draft says that the PAD processing in RFC 4301 needs to be updated for this draft, so the draft updates RFC 4301.

- Implementations of RFC 4301 that do not care about IKEv2 using this draft should not be updated, so this draft doesn't update 4301, just the 4301 processing when using IKEv2 and this draft.

I tend toward the second interpretation, but am happy either way. What do others think?

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 27 Feb 2015 23:58:11 +0200

> I tend toward the second interpretation, but am happy either way. What do others think?

I tend the other way, so we need an example or two. If you read the 
abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates 
both RFC 3168 and RFC 4301 to add new behaviours for previously unused 
combinations of inner and outer headers." Which means that even though 
existing implementations are not affected until they encounter these new 
message variants, we use "Updates" because new implementations are 
expected to include the new behavior.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Feb 2015 14:21:21 -0800

On Feb 27, 2015, at 1:58 PM, Yaron Sheffer <[email-masked]> wrote:
> I tend the other way, so we need an example or two. If you read the abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers." Which means that even though existing implementations are not affected until they encounter these new message variants, we use "Updates" because new implementations are expected to include the new behavior.

That's an interesting example, one from outside our WG. Note, however, that RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that it is the only one like this draft that says "and you need to change your PAD processing for this new thing".

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 28 Feb 2015 08:24:49 +0200

> That's an interesting example, one from outside our WG. Note, however, that RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that it is the only one like this draft that says "…
Similarly, RFC 5282 Updates RFC 4306. Even though you only needed to 
change your implementation if you added AEAD. But it's not very 
important either way.

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Feb 2015 16:36:50 -0500 (EST)

On Sat, 28 Feb 2015, Yaron Sheffer wrote:

>>> abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates both 
>>> RFC 3168 and RFC 4301 to add new behaviours for previously unused 
>> That's an interesting example, one from outside our WG. Note, however, that 
>> RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that 
>> it is the only one like this draft that says "and you need to change your 
>> PAD processing for this new thing".
>> 
> Similarly, RFC 5282 Updates RFC 4306. Even though you only needed to change 
> your implementation if you added AEAD. But it's not very important either 
> way.

I'm not sure what the IETF definition is for "Update an RFC". I would
say this RFC only adds to 4306. That is, if you do not implement this
document you do not need to know about this "update". I would expect an
"updated by" to be mandatory reading material for an implementor of the
RFC being updated.

I'm fine either way, but I am leaning towards not specifying updated by.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 1 Mar 2015 09:59:22 +0300

> "updated by" to be mandatory reading material for an implementor of the

I agree with Paul that the term "update an RFC" is not clear enough
and could be treated differently. BTW is there some formal definition
of this term (like definitios of uppercase words in RFC2119)?
This would clarify the situation.

> I'm fine either way, but I am leaning towards not specifying updated by.

I'm also fine with either way.

Valery.