Re: AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13
Magnus Westerlund <[email protected]> Mon, 18 Feb 2008 16:41:57 +0100
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
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 protected] > ---------------------------------------------------------------------- > > > _______________________________________________ > rserpool mailing list > [email protected] > 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 protected] ----------------------------------------------------------------------