Subject: RE: [Speermint] ENUM: Reachability

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 4 Apr 2006 13:33:03 -0600

Good question...I brought this up at the WG meeting last month.  ENUM is
heavily referenced within the SPEERMINT WG's terminology and
requirements draft.  Although I fully expect ENUM to be part of some
aspect of varying peering topologies, I do not think it is the only
"location mechanism".  I believe this was agreed upon at the WG meeting;
therefore, consider it in context as an inclusive, but not exclusive
method.

--Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 1:21 PM
To: Malas, Daryl; 'Stastny Richard'
Cc: [email-masked]
Subject: RE: [Speermint] Reachability

Hi Darryl/Richard,
Just a quick question: did the WG decide on ENUM/DNS as the location
mechanism already? (could be, I joined late)  
I like the idea, but it's having the tail wag the dog.  ;)
Seriously, though - we may find a missing piece or 2 if we start with
terminology + requirements.  Sorry if I mis-interpreted your comments.

-hadriel

> -----Original Message-----
> From: Malas, Daryl [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 1:34 PM
> To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> Comments in-line...
> 
> Daryl M.
> 
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 11:27 AM
> To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> [email-masked]
> Subject: Re: [Speermint] Reachability
> 
> Nice analysis, and useful
> 
> But I think we get more and more down to L2 and L3, but our prime
> or first goal is to enable peering on L5.
> to do so, we basically need a common database to get the routing
> information
> 
> [Daryl]  I agree, by defining the environment (e.g. public, private,
> carrier), I think it will be easier to specify the required database.
> 
> Of course any provider can peer with ony other provider bilaterally
> as he likes, if he has finally found out which VPN or other bi-lateral
> peering on Ip level he wants to use.
> 
> [Daryl] Agreed.
> 
> He could do this by interrogating his own local databases,
> (which he has to maintain by himself, spendig a lot of money and
> making a lot of mistakes) or he may interrogate a common global
database
> e.g. the DNS (both for SRV and ENUM)
> 
> [Daryl]  I think this is a little presumptuous, but is ultimately
their
> choice.  If their choice is not to use DNS, then another more cost
> effective method may be used by the operator (i.e. think along the
lines
> of class 4 switching), as long as it is within the specific
environment
> (e.g. private/carrier peering...basically eliminates public peering if
> not DNS).
> 
> I know that split horizon DNS may be used, but the drawback of
> this is that the DNS behind the curtain must be administrated by
himself
> 
> So the prime question in ENUM WG is where to place a globally
> reachable ENUM DNS and the question in speermint WG is what
> information has to be placed in the public DNS.
> 
> [Daryl] I think this is the only method capable of supporting a public
> peering model.
> 
> Both can only be in the public address spece to be useful, and
> therefore everybody needs access to thsi address space.
> 
> If they then do peering by whatever means on l3, so they could
> 
> Richard
> 
> ________________________________
> 
> Von: Malas, Daryl [mailto:[email-masked]]
> Gesendet: Di 04.04.2006 19:09
> An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> [email-masked]
> Betreff: RE: [Speermint] Reachability
> 
> 
> 
> Okay, I apologize for jumping into the middle of this, but I wanted to
> add my two cents.  I think by now it should be generally understood,
if
> you want to interconnect with non-RFC1918 address spaces; you need to
> utilize a method (any number of options, such as STUN, B2BUA,
> etc...etc...)in order to be addressable and routable on the public
> registered address space.  This being said, I think peering will be
> applicable in 3 different environments:
> 
> 1.  Public peering (somehow connected and routable by the public
> internet)
>         a.  Public addressable space
>         b.  Routed across the public internet
>         c.  Media and signaling accessible from the public internet
>                 1.  May be encrypted for privacy reasons
>                 2.  Authentication mechanisms likely in place
> 2.  Private peering (either public addresses (non-routable to the
> internet) or RFC1918 address space)
>         a.  Public address space -- not routed via the Internet
>         b.  RFC1918 address space -- non-NAT req'd
>         c.  Little or no security likely implemented
>         d.  Not accessible from the public internet (may be
accomplished
> by          private tunnels l2TP, PPTP, IPSEC, etc.)
> 3.  Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918
> or non-RFC1918 address space as necessary)
>         a.  Utilizes public or private addresses
>         b.  Intended capabilities such as l2vpn or l3vpn for
> interconnection
>         c.  Media and signaling are not accessible from the public
> internet
>         d.  Primarily intended for peering between carriers as opposed
> to          enterprises (this might include "Federations" depending on
> def.).
> 
> Does it make sense to break up the issues/requirements based on these
3
> different environments?
> 
> Daryl M.
> 
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 10:45 AM
> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
[email-masked]
> Subject: Re: [Speermint] Reachability
> 
> >Most consumers on the planet Earth are in private address spaces at
> this
> >point I think (i.e., 192.168.x.x), and many Enterprises are as well.
> Entire
> >networks in some countries are privately addressed, yet they are
> members of,
> >and use, the Internet.
> 
> Yes, but if you put your mailserver  only in 192.168.x.x, you will get
a
> problem
> 
> Richard
> 
> ________________________________
> 
> Von: Hadriel Kaplan [mailto:[email-masked]]
> Gesendet: Di 04.04.2006 18:22
> An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';
> [email-masked]
> Betreff: RE: [Speermint] Reachability
> 
> 
> 
> Hi Richard,
> And here we get to the fun stuff.  :)
> 
> The idea of every serving proxy/registrar/sip-node needing to be
> publicly
> addressable is neither an Internet requirement, nor a requirement of
the
> IETF.  Entire working groups in the IETF concern themselves with
> allowing,
> enabling, and inter-working private address spaces and VPNs.  What's
> missing
> is how to join them at the application and transport layer, when that
> application layer embeds addressing in itself.
> 
> Most consumers on the planet Earth are in private address spaces at
this
> point I think (i.e., 192.168.x.x), and many Enterprises are as well.
> Entire
> networks in some countries are privately addressed, yet they are
members
> of,
> and use, the Internet.  There are also now 2 disjoint address groups
> defined
> by the IETF, as you know: IPv4 and IPv6.  There are mechanisms to try
to
> provide interoperation/migration support for them, but that typically
> requires intermediaries.
> 
> So I agree with you there needs to be an entity providing an ingress
> (and
> egress) point(s), either on the public network for it to be public, or
> for
> it to cross into another private address domain.  For this WG's
purpose,
> I
> recommend we allow either model to work, as well as the model of the
> private
> going to public (and vice-versa) so long as the peering element of
both
> sides are in the same public or private space.
> 
> -Hadriel
> 
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Tuesday, April 04, 2006 9:55 AM
> > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan;
> [email-masked]
> > Subject: Re: [Speermint] Reachability
> >
> > >The conclusion here -- every endpoint and every serving
> proxy/registrar
> > >needs to be publicly addressable.
> >
> > This was my basic assumption, and I seemed not so clear to
everybody.
> > This was also why I had a problem with Sohel's presentation at the
> IETF,
> > because I did not see any public adressable entities AT ALL.
> >
> > For the avoidance of doubt: I have no problem if the same peering
> > principles we develop here are used between some entities in a
private
> > network,
> > but it is not out task to consider this separately. Because if it
> works
> > on the Internet, it also works in a private network (extranet in
this
> > case)
> > (see DNS). this private network may even use public IP adresses, but
> if
> > the
> > are not routable from the public Internet, they are could as well be
> > private
> > (example IPX)
> >
> > What never can work is a peering between one entity on the public
> network
> > and one on a private network. The private entities need at least to
> have
> > one
> > ingress element on the public network
> >
> > Richard
> >
> > ________________________________
> >
> > Von: Patrick Melampy [mailto:[email-masked]]
> > Gesendet: Di 04.04.2006 15:29
> > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; [email-masked]
> > Betreff: RE: [Speermint] Reachability
> >
> >
> >
> > Reinaldo -- I agree with your assertions.
> >
> > But I want to ensure everybody understands what your really saying
> here.
> >
> >   Before somebody mentions it...for a UA behind a NAT to be
reachable,
> >   he/she needs a public NAT binding so that a session _initiated_
from
> the
> >   public side can be made to him/her.
> >
> > This means that for carrier to carrier peering models, each and
every
> > customer of every carrier that wants to inter-connect needs to have
a
> > 'public NAT binding'.
> >
> > I believe by extension, this means that a serving proxy/registrar
for
> the
> > target of a communication must ALSO have either a public address or
a
> > public
> > NAT binding.
> >
> > The conclusion here -- every endpoint and every serving
> proxy/registrar
> > needs to be publicly addressable.
> >
> > Am I correct?
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Tuesday, April 04, 2006 5:29 AM
> > To: Hadriel Kaplan; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > Hello Hadriel,
> >
> > Comment inline....
> >
> > > -----Original Message-----
> > > From: Hadriel Kaplan [mailto:[email-masked]]
> > > Sent: Monday, April 03, 2006 11:01 PM
> > > To: Reinaldo Penno; [email-masked]
> > > Subject: RE: [Speermint] Reachability
> > >
> > > Hi Reinaldo,
> > > Comments inline...
> > >
> > > > -----Original Message-----
> > > > From: Reinaldo Penno [mailto:[email-masked]]
> > > >
> > > > Maybe I'm missing something, but given that this workgroup is
> > interested
> > > > only in call routing (E.164 is out of scope), do we really need
to
> > care
> > > > about that? An AoR in the end will be translated to an IP
address,
> > and
> > > > IP addresses have a very good definition of public and private
(in
> > IPv4
> > > > and IPv6).
> > >
> > > I don't understand fully what you mean.  An AoR is only fully
> > "translated"
> > > to an IP Address (and really to a contact URI) by the AoR's
domain.
> > So
> > > what
> > > you're saying is if the AoR's user-part represents a consumer
behind
> a
> > > home
> > > NAT (a private IP), then it is a private AoR; but for those
> consumers
> > who
> > > don't use home-NATs then it's a public AoR?
> > [[Reinaldo]]
> >
> > Hello,
> >
> > Actually I'm trying to understand the whole purpose of the
discussion,
> > that's why I gave that example. I was trying to understand why it
> > matters, before getting knee deep into the classification. Can
someone
> > refresh that for me?
> >
> > So, if SIP peering is going to get woven into the fabric of the
> > internet, the rules for domains names, DNS resolution, private vs.
> > public IP address, etc should apply, right?
> >
> > I believe the current model of host to host or email communication
is
> > not different for SIP. We could have the following main
> > situations...(correct me where I'm wrong).
> >
> > 1) The AoR (just like a traditional domain name or email), in the
end
> > will get resolved into an IP address. Then there are only two
> > situations.
> >
> >    a) the IP address is private (RFC 1918).
> >
> >    This means the SIP endpoint is unreachable unless you are also in
> the
> > same private network. Actually I believe a private IP address cannot
> > even be provisioned in a public DNS.
> >
> >    Before somebody mentions it...for a UA behind a NAT to be
> reachable,
> > he/she needs a public NAT binding so that a session _initiated_ from
> the
> > public side can be made to him/her.
> >
> >    b) the IP address is public.
> >
> >    The SIP endpoint is theoretically reachable.
> >
> > 2) The AoR cannot get translated. Again, just like the Internet we
> have
> > today, this means the domain name/user is private, does not exist,
etc
> >
> > All this has been happening okay with just a few basic rules. If an
> AoR
> > is very similar to an email address, why it would not work with the
> > current infrastructure/definitions?
> >
> > If somebody says that they have a "private" email address or domain
> > name, what is your interpretation of that?
> >
> > Regards,
> >
> > Reinaldo
> >
> >
> >
> >
> >
> >
> >  And if the AoR gets
> > > translated
> > > into an IP by a registrar inside a private IP subnet, and somehow
it
> > later
> > > gets translated into the public IP address space, that's also
> private
> > > because the AoR was translated to a private IP originally?
> > >
> > > Or maybe you mean what the domain part of the AoR resolves to?
> > >
> > > > For you to be "SIP reachable", you need to be IP reachable
first,
> > let's
> > > > not forget about that. And if you are IP reachable, you could
> > > > potentially be SIP reachable by registering to some free SIP
> service
> > (or
> > > > the SIP "domain" above you in the hierarchy...if this was the
> > email/DNS
> > > > model).
> > >
> > > Actually, to be very specific ultimate target of the AoR can be
"sip
> > > reachable" but not IP reachable.  But I think for now we should
> ignore
> > the
> > > implications of that, unless it becomes a problem.
> > >
> > > -hadriel
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> 
> 
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

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

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 4 Apr 2006 21:40:38 +0200

To clarify, ENUM is not a location mechanism
it is a mapping from E.164 numbers to AoR
 
Call routing on IP is only done via AoR
 
so AoR is the output from ENUM, which is the input to speermint
 
Richard

Von: Malas, Daryl [mailto:[email-masked]]
Gesendet: Di 04.04.2006 21:33
An: Hadriel Kaplan; Stastny Richard
Cc: [email-masked]
Betreff: RE: [Speermint] ENUM: Reachability

--Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, April 04, 2006 1:21 PM
To: Malas, Daryl; 'Stastny Richard'
Cc: [email-masked]
Subject: RE: [Speermint] Reachability

Hi Darryl/Richard,

-hadriel

database
their
lines
environment
himself
if
accomplished
3
[email-masked]
a
the
this
members
to
purpose,
both
everybody.
private
this
reachable,
from
every
a
for
a
to
address,
(in
domain.
behind
discussion,
someone
is
end
etc
it
first,
"sip