Subject: [NSIS] AD comments on draft-ietf-nsis-ntlp-14

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Nov 2007 17:09:45 +0100

Hi,

I am sorry for the long time this AD review has taken. I really liked to
read the document from first to last word before progressing it. I have
now done this and thinks the document is in pretty good shape. I would
appreciate an updated version as soon as we have resolved the questions.

1. Page 29:
"   2.  The signalling application does not wish to set up state with the
       Querying node and become its peer.  This includes the case where
       a node wishes to avoid taking part in the signalling for overload
       protection reasons.  GIST MUST propagate the Query, similar to
       the case described in Section 4.3.4.  No message is sent back to
       the Querying node.  The application MAY provide an updated NSLP
       payload for the same NSLPID, which will be used in the Query
       forwarded by GIST.  Note that if the node which finally processes
       the Query returns an Error message, this will be sent directly
       back to the originating node, bypassing any forwarders.  For
       these diagnostics to be meaningful, any GIST node forwarding a
       Query MUST NOT modify it except in the NSLP payload and GIST hop
       count; in particular, it MUST NOT modify any other GIST payloads
       or their order.  An implementation MAY choose to achieve this by
       retaining the original message, rather than reconstructing it
       from some parsed internal representation."

I can't quite understand "For
       these diagnostics to be meaningful, any GIST node forwarding a
       Query MUST NOT modify it except in the NSLP payload and GIST hop
       count; in particular, it MUST NOT modify any other GIST payloads
       or their order."

Why does a forwarding node may modify the NSLP payload? Can you please
explain this? GIST hop is clearly

2. Section 5.3.2.2:

"   The upper layer protocol MUST be UDP without intervening
   encapsulation layers.  Following the hop-by-hop option header, the IP
   header MUST NOT include any extension headers other than routing
   options or destination options, and for the last extension header
   MUST have a next-header field of UDP."

Here I must actually ask if this specification really can require that
other IP extensions not are used. This seem to have potential clashes
with other basic building blocks. So I would like to understand why the
WG thinks it is necessary to make these restrictions.

3. Section 5.3.3, page 59:

"A suitable approach
   is to restrict the token bucket parameters so that the mean output
   rate is a small fraction, such as 5%, of the node's lowest-speed
   interface."

I think it should be made clear that the token bucket parameter for
bit-rate is "no larger than 5%" rather than suggesting that 5% is a
general good value.

4. Section 5.7.3.1:

"For
   example, *.example.com in the APD would match certificates for
   a.example.com, foo.example.com, *.example.com, etc., but would not
   match example.com.  Similarly, a certificate for *.example.com would
   be valid for APD identities of a.example.com, foo.example.com,
   *.example.com, etc., but not example.com."

Is it intentional to have two sentences saying the same thing, or am I
dense here. It looks very much like a repeat.

5. Section 9: NSLP ID

I actually wonder about the selection of IESG approval for new NSLP IDs.
 Isn't that kind of restricting? Sure, it can potentially be easier to
register than specification required. However, it does put load on the
IESG. It also assumes that the IESG will have enough clue in the future
to know what the correct way to handle a registration requests. Can
someone provide me with the WGs reasoning behind this policy?

6. Appendix A. I think the text about "reserved" and its meaning needs
to be moved from section A.2 to the front text for Appendix A. Otherwise
it is wrongly scoped and does not cover A.1 or any A.3...

7. Section A.1: There is no explicit mention of what values should be
listed in the version field for this spec. Earlier it says this is
Version 1 of GIST, but that could be encoded both a 0 and 1 in this
field based on previous protocols from IETF.

8. ID-nits warnings:

  == Unused Reference: '14' is defined on line 5231, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2246 (ref.
     '15') (Obsoleted by RFC 4346)

  -- Obsolete informational reference (is this intentional?): RFC 2766 (ref.
     '18') (Obsoleted by RFC 4966)

  -- Obsolete informational reference (is this intentional?): RFC 2960 (ref.
     '19') (Obsoleted by RFC 4960)

I definitely like to know if the new versions are fine or not.

  == Outdated reference: A later version (-04) exists of
     draft-ietf-behave-turn-03

  == Outdated reference: A later version (-15) exists of
     draft-ietf-nsis-nslp-natfw-14

  == Outdated reference: A later version (-02) exists of
     draft-pashalidis-nsis-gist-legacynats-01

  == Outdated reference: A later version (-05) exists of
     draft-pashalidis-nsis-gimps-nattraversal-04

  == Outdated reference: A later version (-04) exists of
     draft-ietf-nsis-ntlp-statemachine-03

  == Outdated reference: A later version (-08) exists of
     draft-ietf-tcpm-tcpsecure-07

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Nov 2007 16:52:32 -0000

magnus,

thanks for the encouragement.

i'll send a separate response for your comments (1) and (2) 
[which need some work].

for the rest, i have proposed solutions below - discussion welcome.

robert h.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: 26 November 2007 16:10
> To: [email-masked]; NSIS
> Subject: AD comments on draft-ietf-nsis-ntlp-14
> 
> Hi,
> 
> I am sorry for the long time this AD review has taken. I 
> really liked to read the document from first to last word 
> before progressing it. I have now done this and thinks the 
> document is in pretty good shape. I would appreciate an 
> updated version as soon as we have resolved the questions.

[snip]

> I think it should be made clear that the token bucket 
> parameter for bit-rate is "no larger than 5%" rather than 
> suggesting that 5% is a general good value.

something like:
A suitable approach is to restrict the token bucket parameters so that
the mean output rate is a small fraction of the node's lowest-speed
interface. It is RECOMMENDED that this rate is no more than 5%.

(I don't think this can really be MUST - a silly counterexample would be
a terabit router which you can telnet into over GSM. but the RECOMMENDED
should make it clear to the implementor that this is a serious piece of
advice.)

> Is it intentional to have two sentences saying the same 
> thing, or am I dense here. It looks very much like a repeat.

Not quite:
*) The first sentence states that if you populate your authorised
peer database with an entry like
*.example.com	ALLOW
then a node presenting a certificate with an identity like a.example.com
will be authorised.
*) The second sentence states this if you have an entry in your APD like
a.example.com	ALLOW
then a node presenting a certificate presenting the identity
*.example.com will be authorised.

>  Isn't that kind of restricting? Sure, it can potentially be 
> easier to register than specification required. However, it 
> does put load on the IESG. It also assumes that the IESG will 
> have enough clue in the future to know what the correct way 
> to handle a registration requests. Can someone provide me 
> with the WGs reasoning behind this policy?

Here there may be some history (John channelling your predecessor
ADs). I think the rationale is as follows:
- IESG review includes standards action as a sort of sub-case
- we didn't want a plethora of proprietary protocols
- we anticipated that one source of proposals would be SDOs
  (for which the evaluation needs to take into account the IETF's
  interaction with that SDO in handling some bigger standardisation
  question, and so is not simply a matter of expert review)

It's obviously easy to modify the assignment rules, and to be honest
I have no really strong opinions against a more relaxed set of
policies here.

> 
> 6. Appendix A. I think the text about "reserved" and its 
> meaning needs to be moved from section A.2 to the front text 
> for Appendix A. Otherwise it is wrongly scoped and does not 
> cover A.1 or any A.3...

OK

> 
> 7. Section A.1: There is no explicit mention of what values 
> should be listed in the version field for this spec. Earlier 
> it says this is Version 1 of GIST, but that could be encoded 
> both a 0 and 1 in this field based on previous protocols from IETF.

I would say '1'. 

>      reference was found in the text

I would propose to add that as an additional reference (alongside the
framework).

>      '15') (Obsoleted by RFC 4346)

aaaaaaaaaaaaargh - the TLS specification version game ...

The place where this is referred from (section 5.7.3) was worked
over in conjuction with the security ADs; note that there is a
normative reference to 4346 also. but since we allow falling back to 
v1.0, we have this reference also. 

[this particular open sore seems to pop up for any protocol which
can be layered on TLS - see the discussion on
draft-ietf-atompub-protocol
for example. in this particular case, i think the text and references
are OK. personally I think it would be more rationale for the
reference to 2246 to be normative, but then we would get into a much
more complicated set of procedural questions.]

>      '18') (Obsoleted by RFC 4966)

will update

>      '19') (Obsoleted by RFC 4960)

will update

> I definitely like to know if the new versions are fine or not.

summary: yes for all of them, but the informational reference
to TLS1.0 should remain (IMHO).

>      draft-ietf-tcpm-tcpsecure-07

will fix all of these. nice to see that we have ony fallen
one version behind.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Nov 2007 17:14:10 -0000

hi magnus,

on your point (2): 

> Here I must actually ask if this specification really can 
> require that other IP extensions not are used. This seem to 
> have potential clashes with other basic building blocks. So I 
> would like to understand why the WG thinks it is necessary to 
> make these restrictions.

This text came in response to review comments, mainly from
the security and routing people. The reasoning behind the text is
in two parts.

Firstly, consider the current set of IPv6 options which aren't
actually upper layer protocols. From IANA, they are:

        00 = Hop-by-Hop Options
        41 = ipv6
        43 = Routing
        44 = Fragment
        51 = Authentication
        60 = Destination Options
        50 = Encapsulating Security Payload
        xx = Upper Layer Header
        58 = Internet Control Message Protocol (ICMP)
        59 - no next header

So the text is ruling out ip in ip (which would make no sense 
for Q-mode), fragmentation (which should not be necessary),
esp/ah (which would prevent GIST working at all), and ICMP
(which is really an upper layer protocol anyway). 

In terms of future IPv6 options, we need to wonder what could
exist other than hop-by-hop or destination options. I'm not
sure what those would be, but quite likely those options would
have some non-trivial impact on the way that the network layer
processed packets (e.g. how they were forwarded). But the correct
operation of GIST (in Q mode) depends rather closely on its
correct interaction with the network layer. So, arbitrarily using
other options would be a source of danger.

>From another point of view, think of the process of defining a
new IPv6 option. The spec is basically saying that you can't use
that option and GIST Q-mode at the same time, without updating the
GIST spec itself - which would be the trigger for some re-analysis
to find out if the combination was safe. If (somehow) you are 
forced to use the new option, then you cannot use GIST; if you 
have freedom about whether to use the new option (which would 
surely be the normal case), don't use it with GIST Q-mode.

To me, these restrictions seem reasonable - is more rationale 
required?

robert h.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Nov 2007 11:05:44 +0100

Thanks Robert,

This makes sense.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Nov 2007 11:56:26 +0100

See inline

> should make it clear to the implementor that this is a serious piece of

Yes, that seems reasonable.

> *.example.com will be authorised.

Okay

> I have no really strong opinions against a more relaxed set of

Okay, as long as the WG knows what it is getting itself into. My main
concern was that being restricted will in fact hamper deployment. But it
appears that you like to avoid proprietary NSLPS. If that is the WG's
conclusion I am fine.

>> both a 0 and 1 in this field based on previous protocols from IETF.

Sure, but can we please get some word in there saying that.

> more complicated set of procedural questions.]

Sure, I should have reacted to that being TLS. I know from the
discussion that it is fine to refer to earlier version.

> to TLS1.0 should remain (IMHO).

Sure

> will fix all of these. nice to see that we have ony fallen

No, problem. I know it is basically impossible to keep all draft
references upto date.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Nov 2007 16:39:03 -0000

magnus,

finally following up your comment (1): 

> Why does a forwarding node may modify the NSLP payload? Can 
> you please explain this? GIST hop is clearly

The question ends in "mid-air", but I can comment on the NSLP payload
aspects. Basically, when a Query message is forwarded along a path,
NSLPs are allowed to inspect and modify the payload. The end result
is that there is a single GIST peering relationship, but where the 
NSLP nodes at each end have gathered some additional data about the
signalling application state at nodes between the peers.

Note that GIST doesn't make any reliability or integrity promises 
about the transmission of this payload - it's just NSLP data being 
piggybacked on the handshake, so there are no constraints (imposed 
by GIST) on what can be done to it. However, GIST itself doesn't 
allow changes in the GIST payloads at these intermediate points, 
because then error reporting wouldn't work.

The canonical example is RMD operating edge-to-edge across a
domain. The ingress sends a GIST query to the egress and these
then peer with each other (statefully, creating a messaging
association, including storing reverse path state and so on). 
As the peering is set up (and when routing state is refreshed)
the Query also gathers RMD state information from the interior
nodes, which however don't store any RMD or GIST per-flow state.

robert h.