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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Feb 2008 16:41:57 +0100

Hi,

I am expecting another updated to ASAP to handle these last comments 
regarding the IANA code points.

Cheers

Magnus

Magnus Westerlund skrev:
> Michael Tuexen skrev:
>>>>>
>>>>> 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.
>>> 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.
>> 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?
> 
> 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.
> 
> 
>>>>> 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.
>>> 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.
>> 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 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.
> 
> 
> 
>> 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?
> 
> 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
> 
> 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
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
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]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Feb 2008 16:43:58 +0100

To me it looks like Common Parameters are ready to be IETF last called.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Feb 2008 17:23:11 +0100

Hi,

I think the update provided in November solved most of the issues for 
ENRP. However, there are still a few that I am missing answers or 
resolution to. It might be that I am missing some explanation email to 
these issues. Please help me ensure that we take care of all the issues.

Magnus Westerlund skrev:
> ENRP:
> 
> E4. Section 2.3: What I don't understand is why the Pool Entry format
> isn't a TLV in itself with the sub TLVs so that one can skip all the PEs
> to the next Pool Entry.
> 
> E6. TAKEOVER: I am bit frightened that a malicious server that ignore
> ENRP_PRESENCE message can force a takeover. No one can protest a single
> bit. I also find it strange that there is no "R"eject bit in the
> ENRP_INIT_TAKEOVER_ACK. If two servers that initiated takeover at the
> sametime reach each other there are no way to indicate that you are the
> looser and I reject your initiation because I am the winner.  See also
> below.
> 
> 
> E22, section 3.10.2: How long is the TAKEOVER_ACKS valid? I guess there
> is an assumption that the Initiating server will send an enforcement as
> soon as it has received ACKs from all other.
> 
> 
> E25. Section 5: Well known Port registration for ENRP?
> 

Cheers

Magnus Westerlund

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 22 Feb 2008 17:54:53 -0600

Hi, Magnus,

Let me to try to give an answer to the questions.

>> isn't a TLV in itself with the sub TLVs so that one can skip all the PEs

For the integrity of the pool, the receiver MUST NOT skip a Pool Entry. 
For this reason, TLV is not use for the Pool Entry for compactness of 
the message (we are more concerned about the size of the message here: 
ENRP_HANDLE_TABLE_RESPONSE message is potentially the biggest msg in the 
protocol).

>> looser and I reject your initiation because I am the winner.  See also

Firstly, we assume that mutual trust among servers are ensured. We also 
have the tie-break algorithm that is based on the "when sense a 
competition, alway back-off" principle and the server IDs give a 
deterministic order to break any tie. Full details of this is given in 
Section 3.5.1.

>> soon as it has received ACKs from all other.

Yes, the enforcement is the sending of the ENRP_TAKEOVER_SERVER message 
by the Initiating server, as specified in the following text:

"  Once the initiating server has received the ENRP_INIT_TAKEOVER_ACK
   message from all of its currently known peers (except for the target
   server), it MUST consider that it has won the arbitration and MUST
   proceed to complete the take-over, following the steps described in
   Section 3.5.2.

3.5.2.  Take-over Target Peer Server

   The initiating ENRP server MUST first send, via an announcement, an
   ENRP_TAKEOVER_SERVER message to inform all its active peers that the
   take-over is enforced.
"

>> E25. Section 5: Well known Port registration for ENRP?

Yes.

regards,
-Qiaobing

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Feb 2008 11:41:56 +0100

> ENRP_HANDLE_TABLE_RESPONSE message is potentially the biggest msg in the 

Okay.

> deterministic order to break any tie. Full details of this is given in 

Okay, that sounds okay.

>   ENRP_TAKEOVER_SERVER message to inform all its active peers that the

Okay, seems to be no problem.

>>> E25. Section 5: Well known Port registration for ENRP?

Okay, such a registration is missing. And I guess that "Registered" port 
is sufficient for ENRP. But please update the draft to include such a 
request.

Cheers

Magnus Westerlund