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

[Magnus Westerlund <[e-mail]>]

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------


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