Hi all, Prior to London, I had suggested to Itujun that I could supply text for this work on the use of anycast with SCTP. SCTP potentially has some very useful features that could mesh well with anycast, and get over some of the difficulties of using anycast.
Unfortunately, I ran out of time and was not able to produce the text. If there is interest, I could see about writing something up. thanks, John PS - I agree that this is a useful document and we should get it to move forward. > -----Original Message----- > From: ext Erik Nordmark [mailto:[EMAIL PROTECTED]] > Sent: 05 June, 2002 19:46 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis > > > The anycast-analysis has been sitting in front of Thomas and > I for quite a long > time while we were trying to figure out if the IETF needs to > do something more > significant in the anycast space (such as an anycast WG; such > as a way to > resolve or at least document the differences between the IPv4 > DNS anycast > usage and the IPv6 architecture). But it is time to finish > this document since > it provides useful information. > > So here are our comments on > draft-ietf-ipgnwg-ipv6-anycast-analysis-00.txt > > In general this is a quite useful document since it attempts to write > things down that haven't been written down before. But it > makes sense to > make the document more clear and succinct, and perhaps also to > add some missing pieces to give a more complete picture. > > Note that there are duplicate comments from Erik and Thomas > here - hopefully > they are consistent and not contradictory :-) > > Comments from Erik > ------------------ > > I completely fail to see what section 1.1 is trying to say > other than "there are different forms of anycast". > > It assigns the tag "BGP" anycast to both the Hardie and > Ohta-san document, > even though only the latter is an interdomain anycast scheme. > And contrasting this against RFC 1546 seems odd, since RFC > 1546 doesn't > say anything whether it limits itself to intradomain anycast or not. > > Section 1.1 doesn't mention (but section 2.1 does) that RFC > 1546 and RFC 2373 > are different with respect to being able to syntactically distinguish > between unicast and anycast, which seems to be an important technical > difference. > What high-level thing is section 1.1 trying to say? > > > RFC2373 IPv6 anycast is very similar to RFC1546 IPv4 anycast. The > > Given RFC 1546's suggestion to use a separate range of addresses > for anycast, this doesn't seem to be true. > > > BGP anycast tries to replicate unicast servers in distant > domains. The > > distribution of servers is worldwide. BGP anycast is being used for > > specific upper-layer protocols only, like DNS and HTTP. There is no > > consideration given for the cases when a client contacts multiple > > servers by chance (transport layer protocol will get > confused), since it > > is unlikely to see BGP route changes during the short > lifetime of the > > transport layer protocols being used. > > While typically http connections might be short, there is nothing in > the http protocol that mandates or assumes that they are short. > > ---- > Section 2.2 says: > After we > have discovered the unicast address of the server, we should use the > server's unicast address for the protocol exchange. > It would be useful to state something about this security implications > (or high-level requirements) when doing something like that in the > security considerations section. > > Section 2.3 should at a minimum have a "not yet" added - the magma WG > is chartered to extend MLD to allow hosts to join anycast groups. > But perhaps it can be written more in the form of > When RFC 2373 was written there was no standard way for > hosts to join anycast groups (short of having the hosts > fully participate in the routing protocol which has trust > issues). Therefore, ... > > If this section talks about the intent to extend MLD to > support anycast, it > would also be useful to add a sentence or two about the > security issues > in this area in the security considerations section. > > Section 2.4 is correct, but doesn't help people understand what > the technical issues are in having a single source address identify > more than one node. Since these implications are not written > down anywhere as far as I know, it would make sense to add > the currently known implications in this document. > > The ones I'm aware of are: > - Incorrect reassembly of fragmented packets due to multiple anycast > members sending packets with the same fragment ID to the > same destination > at about the same time; the same the source IP address, > destination IP > address, nextheader, and fragment ID numbers might be > accidentally used > at the same time by different senders. > > - Errors and other response packets might be delivered to > a different anycast member than sent the packet. This might be > very likely since asymmetric routing is rather prevalent > on the Internet. > > Particular cases of such errors that are known to cause protocol > problems are > - ICMP packet too big making path MTU discovery impossible. > - <others> > The misdelivery of other errors might cause operational > problems - making > the network harder to trouble-shoot when anycast source > addresses are used. > > Section 2.5. > Aren't there also replay protection issues when manual keying is used > for anycast addresses? (Such issues exist for multicast and manual > keying, so I'd be surprised if they didn't exist for anycast.) > > Section 3.1 last paragraph seems to say that anycast can never be > used interdomain due to route scaling issues. This is clearly the > case if there are lots of interdomain anycast addresses being used. > But having lots of global anycast addresses where the anycast members > are in the same topological region, would presumably automatically > be aggregated as part of the prefix for advertised by that topological > region. (Whether one would call this interdomain or intradomain > is an interesting terminology issue; the point is that the anycast > service provided by multiple nodes in a single domain is accessible > from outside the domain.) > > Section 3.4 and 3.5 don't seem to be finished - they just contain > a "TBD". > Is there something which you intended to put in there? > If not, presumably the sections can be dropped. (The document > doesn't *have to* suggest improvement everywhere.) > > Section 4.1 says: > > Note that, however, bad guys can still inject fabricated > results to the > > client, even if the client checks the source address of the > reply. The > > check does not improve security of the exchange at all. > I think that DNS folks would disagree with that. > Having the resolver check the source address of replies > prevents, when ingress filtering is in use, off-path attackers > from spoofing responses. Thus it adds some non-zero amount of > protection to do this. > Same IMHO incorrect statement is repeated in this section: > > The source address check itself has no real protection > > It might make sense, for DNS query/replies over UDP, to instead look > into relaxing the anycast source address restriction under > appropriate constraints (e.g. must not send larger than MIN MTU > since path MTU discovery is unlikely to work). > > Another possibility, which you may or may not want to add to > the document, > is to specify a protocol which can establish a binding between the > anycast address and the unicast address of one of its members > with as much security as the routing system provides for routing > packets to the anycast address in the first place. IMHO such > a protocol > can be built by reusing pieces of MIPv6. > > I think (but I haven't verified) that (many) tftp > implementations verify > the source address. Perhaps I'm confused and it is only the > server that does > this and not the client. But using TFTP as an example of how > secure protocols > should be done is not a very strong argument to say the least. > > NITS: > > > destination node, out of a group of destination nodes. IP > datagram will > s/IP/The IP/ > > > If multiple packets carry an anycast address in IPv6 destionation > Spell check needed - "destionation"? > > > check source address, based on RFC2181 section 4.1. TFTP > The "TFTP" looks like extra characters at the end of the line. > > References: > The Hardie document is now RFC 3258. > > > Comments from Thomas: > -------------------- > > > destination node. The destination node is identified by an unicast > > s/an unicast/a unicast/ > > >destination node, out of a group of destination nodes. IP > datagram will > > s/datagram/datagrams/ ? (or "An IP datagram") > > > based on routing measure of distance. The source node does > not need to > s/on/on the/ > > > Today, there are so-called "anycast" operated mostly for critical > > servers including DNS servers and web servers (like those > for Olympic > > games) [Hardie, 2001; Ohta, 2000] . We call the technique > "BGP anycast" > > Sentence doesn't parse. s/"anycast"/"anycast" services/ > > Also, name "BGP anycast" is not really very > accurate. draft-ietf-dnsop-hardie-shared-root-server-03.txt doesn't > rely on BGP only. The technique works also within a single AS where no > BGP is used. > > > o A provider-independent IPv4 address prefix is allocated > from an RIR. > > Not required that the address be PI. > > > o The address prefix is configured at multiple distant > locations on the > > Internet. > > o BGP routes are advertised from all of the locations. > > Not sure what this means, especially the first bullet. > > > BGP anycast tries to replicate unicast servers in distant > domains. The > > Not sure I agree. The replication is within a single AS. That may or > may not involve services is "distant domains". Maybe you want to say > something like: > > BGP anycast tries to replicate unicast servers in different > topological locations. > > > > distribution of servers is worldwide. BGP anycast is being used for > > specific upper-layer protocols only, like DNS and HTTP. There is no > > Where is it being used for HTTP? The documents you cite talk about DNS > and UDP exclusively. > > > specific upper-layer protocols only, like DNS and HTTP. There is no > > consideration given for the cases when a client contacts multiple > > servers by chance (transport layer protocol will get > confused), since it > > is unlikely to see BGP route changes during the short > lifetime of the > > transport layer protocols being used. > > It is misleading to say this is all a BGP issue. The Hardie document > says that within an AS routes are advertised statically (even if a > particular server becomes unavailable) precisely so that routes stay > pinned and don't change. Note that this is within an AS, so its not > just BGP. > > > RFC2373 anycast is defined in more generic manner, and does > not limit > > the routing infrastructure nor upper-layer protocol, > Therefore, RFC2373 > > The first part of the sentence suggests that 2373 does NOT limit > upper-layer protocols. This would imply that the "BGP" approach > does. Actually, some might argue the opposite. 2373 says a source > address cannot be an anycast address. This implies that higher-layer > protocols that make use of anycast addresses need to be changed to > understand anycast addressing. This is in contrast with the BGP > approach. > > > depending on stability of the routing table. The property > leads to a > > couple of interesting symptoms. > > s/symptoms/observations/ ? > > > protocol exchange. If we use more than 2 packets, 1st and > 2nd packet > > s/exchange/exchanges/ > > Text should make clear that it assumes when server responds, source > address is unicast, not anycast. And point out that this causes > problems for some existing protocols. > > --- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
