Subject: Re: [Rserpool] AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13

From: Michael Tuexen <[email-masked]>
Date: Sat, 17 Nov 2007 14:55:10 +0100

Hi Magnus,

here are the comments to your comments regarding
draft-ietf-rserpool-common-param-13.txt

My comments are based on a telephone conference between
the authors.

I have removed the other text from the mail...

A new version addressing all your comments has
been submitted and is available at
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-14.txt

Best regards
Michael

On Oct 16, 2007, at 6:37 PM, Magnus Westerlund wrote:

>
> COMMON:
>
> C1. Page 6: There is a editors note that should be removed.
Done.
>
>
> C2. Section 3.3: Is it a SCTP limitation that there needs to be the  
> same
> port on all the interfaces or this a limitation created in this
> document? Will not this be problematic to get the same port over all
> interfaces?
I would not call it a limitation of SCTP, but an SCTP endpoint has
one or more IP-addresses (it can be a mixture of IPv4 and IPv6
addresses) and one single port number. This feature is not related
to RSerPool and the message format is correct.
>
>
> C3. Section 3.3, 3.4, 3.5: Probably a question for the utilizing
> protocols. Are it is possible to have multiple transport parameters of
> the same type, for example to provide both IPv4 and IPv6 addresses?
If you want to provide a service on multiple IP addresses and the
same port number, just use multiple transport parameters. This decision
was made a long time ago and provides no limitation.
>
>
> C4. Any considerations for UDP-Lite or DCCP transport parameters?
Thanks for the reminder... I have added transport parameters for
UDP-Lite and DCCP. I think we we re just not aware of these protocols
when we wrote the initial version of the ID.
>
>
> C5. Section 3.6: "   The enforcement rules and handling procedures of
> all the policies are defined in Section xxxxx in ASAP [3]."
>
> This is only one of several occurances of "xxxxx" or "????" where  
> there
> should be a section number from the other specs. Please look through  
> all
> the documents for this type.
>
> See also Section 3.9, Server ID
> Section 3.12: last paragraph
Done.
>
>
> C6. Section 3.8: Registration life: I am missing a time reference  
> here.
>> From when does the time count? Wouldn't it be better with a NTP  
>> time or
> something else? The current construct clearly requires a receiver to  
> at
> least take a clock time and then save arrival time or combine the two
> into an expiration time for the entry.
Yes, the receiver needs to compute the time, it is just a relative  
duration.
There is no problem with this, since any endpoint has to run timers  
and so
on which also include durations.

However, if the duration is very short and the message transfer delay  
large,
your system will not work as expected, but that is true for a lot of  
systems
when used in a way they are not engineered for.
>
>
> C7. Section 3.9:
>
> Multicast flag: In what direction that this flag apply? For the sender
> or the receiver?
Removed.
>
>
> C8. Section 3.10, Figure 16:
>
> I would call this first a figure with the TLV and then the Cause Code
> value to cause code list for a "Table". It is a bit confusing.
Done. This was a consequence of a wrong usage of the .xml tool....
>
>
> C9. Section 3.10.2: Can multiple be unrecognized parameter TLVs be
> included in this?
No. Just use multiple error causes. A text clarification has been added.
>
>
> C10. Section 6. I am missing a security analysis bringing up any  
> issues
> in the parameters themselves.
I do not see any security issue by message formats. Each receiver has
to do input validation, but that it clear and there is nothing special
with the messages defined here.
>
>
> -- 
>
> 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]
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> rserpool mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rserpool
>

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Nov 2007 02:49:50 +0100

Hi Magnus,

please see my comments regarding the ASAP document in-line. Please
note that my comments are based on a telephone conference between
the authors.

A new version addressing all your comments has been uploaded and
is available at
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-18.txt

I'll remove text from your mail not related to ASAP.

Best regards
Michael

On Oct 16, 2007, at 6:37 PM, Magnus Westerlund wrote:

> Hi,
>
> I will bring up all my comments on the core protocol specs in this
> email. I will do my best to keep it structured.
>
> Generally:
>
> G1. There is some confusion over text and where it is defined. I think
> the document would benefit from trying to be more clear on what is  
> used
> in what communications scopes. It is also important to be clear on  
> when
> one is referring to a process in another scope that result in a
> procedure in the scope one currently describes.
>
> I think the specs may need to clarify what needs to be implemented by
> what type of entity. For example the PUs implementation burden is  
> quite
> different from a PE or a ENRP server.
A new section "Roles of Endpoints" has been added to clarify this.
>
>
> G2. At least to me it there are some confusion on how one identifies
> what type of messages are arriving on a server. To my understanding  
> this
> is done by well known ports and also the PPID in SCTP. But this is
> confusing but quite important as the message type space are  
> overlapping
> so the receiver must know which protocol to expect.
A new section "SCTP considerations" has been added to clarify this.
>
>
> G3. I think that section 1, should contain some text on practices used
> in this spec. One is the constants and variables used without
> explanation until one have come through the whole text.
We have added text to section 1 which refers to section 5.
>
>
> ASAP:
>
> A1. Section 3.6: The usage of multicast is very unclear. It seem to be
> very underspecified. For example how does one control the rate of ASAP
> multicasted requests? This seem to be strictly timer based so the
> bandwidth will depend on the number of ENRP servers. So how can one
> congestion control the ENRP to PEs announcement traffic?
We have added text that an ENRP Server sends out a multicast message
every (N+1) * T6, where N is the number of detected ENRP servers.
Therefore there should only be approx. one message every T6.
>
>
> A2. Section 7.2: Also what is the security solution for multicast.
Not sure what the problem is... The receiver should trust the  
information
in the received multicast message the same way as preconfigured  
information.
It gets an address which might or might no belong to a trustworthy
ENRP server. Other mechanisms have t be used for authentication.
>
>
> A3. Section 3.6:
>  "If multicast capabilities are used within the operational scope an
>   ENRP server MUST send periodically every T6-Serverannounce an
>   ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the
>   transport addresses available for ASAP communication on the  
> multicast
>   ENRP client channel."
>
> Which ASAP communication are there transport addresses available in  
> the
> ASAP_SERVER_ANNOUNCE message? To my understanding this is for the
> PE-ENRP communciation.
and for the PU<-> ENRP Server communication.
>
>
> A4. PE ID uniqueness. The text somewhere says that there are no  
> serious
> issue with having two PE pick the same ID. However, it clearly affects
> the pool performance as only one will be able to provide service at  
> any
> given point. And as I understand it they will be performing a tug of  
> war
> around whos values will be registered. I still think that you should
> have implemented a mechanism identifying this and have the PEs draw a
> new PE ID and reregister.
>
This has been discussed a long time ago and the decision was to do
it like it is now...
The collision is not likely, but it can happen. When it happens the
PE which registers later takes over new PU from the old one. No big
deal. It would be much harder to synchronize the ID over the pool.
So for simplicity, we decided just to be able to handle the collision
with no critical consequences.
> A5. Section 2.2.5: There is a no explanation of how one turns of  
> dynamic
> updates.
Dynamic updates happen as long as the SCTP stays up. Text has been added
to specify this.
>
>
> A6. Section 3: "(or equivilant mapped
>   function if using TCP)."
>
> As this can't be a general function, maybe there should be better
> explanation on what type of demultiplexing is needed on a joint data  
> and
> control channel between server and client.
We just removed the TCP mapping.
>
>
>
> A7. Section 3.1: "      R2.3)  Fill in the Registration Life time
> parameter with the
>         number of seconds that this registration is valid for.  Note a
>         PE that wishes to continue service MUST re-register after the
>         registration expires."
>
> Shouldn't "after" in the last sentence be "before"?
Done.
>
>
> A8. Section 3.3: How does one know how long a cache entry is valid?  
> For
> most other protocols it is the serving entity that indicate the  
> validity
> when caching, rather than local policy. Also isn't the stale timer
> associated with the entry rather than the whole cache?
>
The impact of cache-usage depends on the application and policy. I have
added text to state this. I also changed the text that the timer is
for an cache-entry.
> A9. Section 3.5:
>
> How does a PU/PE find the home ENRP server for a particular PE? To my
> understanding the PU/PE only has the ID of the ENRP server, not the
> address. Please include the necessary step to map the ID to an  
> address.
The PU/PE can send the message to any ENRP server. Therefore the  
function
you are talking about is not needed. I clarified the text.
>
>
> A10. Section 3.8, third paragraph:
> "If the PU's ASAP endpoint detects a failure and initiates a failover
>   to a different PE, it SHOULD send the lastest received cookie
>   parameter in an ASAP_COOKIE_ECHO message to the new PE."
>
> When should it send that cookie? Please specify in what protocol  
> step it
> should happen.
The cookie is sent as the first message on the control channel. The
text has been clarified.
>
>
> A11. Section 6:
>
> ASAP well known port registration? Is this not needed as the ENRP
> protocol will always provide the port? Is that true both for PE and  
> ENRP?
Well, only if multicast is used. In the other case, the well known port
is used.
>
>
> A12. Section 6. IPv4 and IPv6 Multicast addresses and ports to be used
> for the ASAP_SERVER_ANNOUNCE?
We already have port numbers assigned by IANA. So we need only multicast
addresses. I have added a sentence about this.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Nov 2007 16:29:54 +0100

Thanks,

I have removed everything that seems clear to me.

Michael Tuexen skrev:
>> C2. Section 3.3: Is it a SCTP limitation that there needs to be the same

Okay, that it is correct is the only thing I needed to know.

> was made a long time ago and provides no limitation.

Ok.

> when we wrote the initial version of the ID.

I have looked at the new transport parameters. I think you will need to
add a DCCP Service Code field also.

>>
>> C6. Section 3.8: Registration life: I am missing a time reference here.
>>> From when does the time count? Wouldn't it be better with a NTP time or
>> something else? The current construct clearly requires a receiver to at
> There is no problem with this, since any endpoint has to run timers and so

Okay.

>>
>>
>> C10. Section 6. I am missing a security analysis bringing up any issues

Sure

So the only thing that still needs fixing seems to be the service code
for DCCP.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Nov 2007 16:58:19 +0100

I have reviewed the changes. Some comments and unfortunately I think
some few additional fixes are needed.

Michael Tuexen skrev:
>> the document would benefit from trying to be more clear on what is used
>> in what communications scopes. It is also important to be clear on when
>> what type of entity. For example the PUs implementation burden is quite

Thanks, this makes this clear.

> Therefore there should only be approx. one message every T6.

Yes, that should resolve it.

> Not sure what the problem is... The receiver should trust the information

Okay, then it maybe should be explicit about that the multicast messages
are not at all trustworthy. I am also worried that one basically can
inject a lot of server announcement messages and that way push the valid
servers into minority so that a client will try all this invalid servers
and never find a valid one.

>>
>>
>> A4. PE ID uniqueness. The text somewhere says that there are no serious
>> the pool performance as only one will be able to provide service at any
>> given point. And as I understand it they will be performing a tug of war

Sure, I can live with it.

>>
>>
>> A8. Section 3.3: How does one know how long a cache entry is valid? For
>> most other protocols it is the serving entity that indicate the validity

Ok.

>> address. Please include the necessary step to map the ID to an address.
> The PU/PE can send the message to any ENRP server. Therefore the function

Ok, the changes solves this.

>> protocol will always provide the port? Is that true both for PE and ENRP?

Please include in the IANA section a listing of the well known ports
that have been assigned. I also think you should include a request to
update the reference for these ports to this document.

> addresses. I have added a sentence about this.

I think you need to expand on this request to correctly request the type
of multicast address you like. Please see RFC 3171.

Cheers

Magnus Westerlund

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Nov 2007 18:11:36 +0100

Hi Magnus,

is changing the DCCP parameter to

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type = 0x3             |      Length = variable        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         DCCP port             |          (reserved)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      DCCP service code                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                     IPv4 or IPv6 Address                      :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

what you want?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Nov 2007 18:36:27 +0100

Hi Magnus,

see my comments in-line.

Best regards
Michael

> some few additional fixes are needed.
No problem, since they improve the document they are welcome!
> and never find a valid one.
That is possible. But using the Multicast messages is completely  
optional.
They are not secured by IPSec or TLS so you can not  trust them...
So what are you expecting here? A sentence or two in the security  
considerations
describing the above?
> update the reference for these ports to this document.
I'm not sure what you want here. If you look at
http://www.iana.org/assignments/port-numbers
and search for asap you will find:

#                          Yoshikazu Watanabe <nabe&sm.sony.co.jp>
asap-tcp        3863/tcp   asap tcp port
asap-udp        3863/udp   asap udp port
#                          Lyndon Ong <lyong&ciena.com> August 2003
asap-sctp       3863/sctp  asap sctp
#                          Lyndon Ong <lyong&ciena.com> November 2005
asap-tcp-tls    3864/tcp   asap/tls tcp port
#                          Lyndon Ong <lyong&ciena.com> August 2003
asap-sctp-tls   3864/sctp  asap-sctp/tls
#                          Lyndon Ong <lyong&ciena.com> June 2006

and for enrp

enrp		9901/udp    enrp server channel
enrp-sctp	9901/sctp   enrp server channel
#			    Lyndon Ong <lyong&ciena.com> June 2006
enrp-sctp-tls	9902/sctp   enrp/tls server channel
#			    Lyndon Ong <lyong&ciena.com> June 2006

If I look at other entries in the document I do not see references
to RFCs.

So would it be enough to just list these assignments in the IANA  
section?

I guess that we should also list the PPID assignments and request an
update for the reference in
http://www.iana.org/assignments/sctp-parameters

SCTP Payload Protocol Identifiers                         Reference
--------------------------------------------------------  ---------
   0 - Reserved by SCTP                                    [RFC4960]
   1 - IUA                                                 [RFC4233]
   2 - M2UA                                                [RFC3331]
   3 - M3UA                                                [RFC4666]
   4 - SUA                                                 [RFC2960]
   5 - M2PA                                                [RFC2960]
   6 - V5UA                                                [RFC2960]
   7 - H.248                                               [H.248]
   8 - BICC/Q.2150.3	                                      [Q.1902.1] 
[Q.2150.3]
   9 - TALI                                                [RFC3094]
  10 - DUA                                                 [RFC4129]
  11 - ASAP       <draft-ietf-rserpool-asap-03.txt>        [Ong]
  12 - ENRP       <draft-ietf-rserpool-enrp-03.txt>        [Ong]
  13 - H.323                                               [H.323]
  14 - Q.IPC/Q.2150.3                                      [Q.2631.1] 
[Q.2150.3]
  15 - SIMCO      <draft-kiesel-midcom-simco-sctp-00.txt>  [Kiesel]
  16 - DDP Segment Chunk                                   [RFC5043]
  17 - DDP Stream Session Control                          [RFC5043]

Do you agree?
> of multicast address you like. Please see RFC 3171.
OK, I need to figure out what we want here...

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Nov 2007 10:31:21 +0100

> is changing the DCCP parameter to

Yes, I think that should work. But I would appreciate if you send the
DCCP WG a notice about this as soon as you have all the text.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Nov 2007 10:42:53 +0100

Michael Tuexen skrev:
> That is possible. But using the Multicast messages is completely optional.

Yes, explaining that there is security issues here, but we are not
resolving them currently. And that with the exception of the DDOS vector
they are any resolved by the later security mechanism.

> So would it be enough to just list these assignments in the IANA section?

I would propose that these registrations are transfered over to IETF and
having the documents actually being referenced. If you search a bit you
will find that some port numbers do have RFC numbers as the reference.

So include the list of port numbers in the relevant drafts and then
include a request to IANA to update these registrations to point at the
documents. I assume Lyndon is fine with this. But he is the current
owner of these registrations so he probably needs to notify IANA that he
is fine when they actually process the request.

>   8 - BICC/Q.2150.3                                         
> [Q.1902.1][Q.2150.3]
>  14 - Q.IPC/Q.2150.3                                     
> [Q.2631.1][Q.2150.3]

You shouldn't list all the PPIDs. Only request that IANA updates the
ones that are created by the RSERPOOL documents to point at the RSERPOOL
documents.

Cheers

Magnus Westerlund