The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)
draft-vanelburg-dispatch-private-network-ind-07

Thank you for addressing the SecDir review comments.  

Thanks for addressing the prior discuss by explaining the risk of spoofing in section 1.2: I would like to understand what prevents spoofing the domain name used in this extension?  The rules included for setting and removing this use of this extension may be enough, but does rely on the security of the devices (proxies) and the network.  As such, it would be helpful to call spoofing out specifically and the mitigations for it in the security considerations section.  It would be helpful to see the set of mitigation described in one spot (Security Considerations).

And I found a couple of nits that would be helpful to correct:

Section 6.1.1 I recommend breaking the first sentence into multiple as it is a bit tough to read.

Security Considerations Section:  Can you add network before "elements" in the first sentence?  In other areas, elements typically refers to data.  Also, traffic should not have an "s" at the end.  
New:
   The private network indication defined in this document MUST only be
   used in the traffic transported between the network elements which are
   mutually trusted

Please do address Spencer's comments and update the applicability section. It not entirely clear to me why we need to be publishing this document, but still, making it clear why we're publishing another P-header would be good.

I can't quite make myself ballot Discuss on this, but I've been through the Discuss criteria twice looking for justification for a Discuss. Please make good choices.

In this text: 1.2.  Applicability

   According to RFC 3427 [RFC3427], P-headers have a limited
   applicability.  Specifications of P-headers such as this RFC need to
   clearly document the useful scope of the proposal, and explain its
   limitations and why it is not suitable for the general use of SIP on
   the Internet.

RFC 3427 was obsoleted by RFC 5727, and since then we've also published RFC 6648 (as a BCP) that explicitly deprecated the use of P-headers in SIP. So, this paragraph would have been about right in 2008, but it doesn't describe reality today.

I'm fine with publishing this specification for a P-header because it's documenting established practice, and section 1.3 of the draft explains that, but I'd prefer that we not publish an RFC in 2014 that seems to say the draft authors were bound by RFC 3427 requirements that no longer apply.

There are, of course, other ways to address this comment, but chopping the first paragraph in 1.2 would work for me.

In this text: 8.  Security considerations

   The private network indication defined in this document MUST only be
   used in the traffics transported between the elements which are
   mutually trusted.  Traffic protection between network elements can be
   achieved by using the security protocols such as IPsec ESP [RFC2406]
   or sometimes by physical protection of the network.  

(I swear this isn't a post-Snowden question) 

This draft was Publication-Requested in its current form because it matches existing deployments, if I'm understanding correctly. Do those existing deployments rely on physical protection of the network for traffic protection?

I'd feel better about allowing this loophole in 2014 if I knew it applied in target deployments.

I've just a bunch of nits. My guess about Specer's
non-post-Snowden question is that probably loads of
IMS stuff assumes physical security, which may well
be questionable. I'd love to be shown that I'm wrong.
I doubt fixing that here is doable though.

I also think Kathleen's discuss is right - calling
out that anyone can spoof the header field values
that are allowed on their n/w would be good.

- 1.2: Is "closed" accurate there really? Just wondering.

- 1.2: RFC 3427 is obsoleted. Does that make any difference
to the applicability statement?  (Funny that the shepherd
write up says this passes the nit checker but the nit
checker in the tracker spots this and the ESP one below.)

- 1.3: Should the section title be "Background"? 

- 3.6: I didn't know what Spec(T) meant. Maybe add a
reference to 3324 section 2.4?

- section 5: By "domain name" do you mean it has to be, or
just often is, a real DNS name? 

- section 7: Does that syntax allow for i18n?

- section 8: RFC 2406 is obsoleted. That should be fixed.

- section 8: Don't you want to allow SIP/TLS too?

- section 8, para 1: Using "ensures the ..." is somewhat
optimistic isn't it? "needs to ensure the ..." would be
better I think.

- section 8: Also just wondering. Given that this header
field name is quite long and assuming for a moment that it
might be the only difference between private and public SIP
messages, might not the message sizes allow someone to
distinguish such SIP messages even if they are encrypted?
Worth noting? I'm not sure, but the example you give is 42
bytes long which could be a nice distinguisher if one
cared.