Subject: [Speermint] Draft-wing-session-auth-00: Media Session Authorization

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Wed, 8 Mar 2006 11:32:48 -0600

Given that propagation delay added for  so much end to end
signaling/control message flows, would it be possible to shorten flows
of Figure 7 by eliminating messages (10 to 13) and combining messages
(9) and (14) together?

 If so, what are the implications of such elimination?

Thank you.

Sohel Khan

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Mar 2006 12:58:13 -0800

> of Figure 7

There is no figure 7.  I believe you're referring to figure 6 on page 9 of
draft-wing-session-auth-00.txt.

> by eliminating messages (10 to 13) and combining messages
> (9) and (14) together?
>

If Alice's network policy allows Alice to send UDP packets out of her
network without any policy control you could eliminate messages 11, 12, 15,
and 16.

It isn't possible to eliminate message 10, as it contains the SDP answer --
that arrives as part of the SIP 183 message (unreliably) or the SIP 200
message.

Message 9 (Alice's STUN response) and message 14 (Alice's STUN Request) are
part of ICE.  Alice can send her STUN response prior to receiving Bob's SDP
answer.  However, per ICE, Alice doesn't send her STUN Request until she
receives Bob's SDP answer.  You'll see those messages 9 (Alice's STUN
Response) and 14 (Alice's STUN Request) are also shown in the simplified ICE
flow in Figure 4.

I expect the mechanics of this will be easier to follow with the slides that
I'm presenting in Dallas -- with the ASCII call flow is awkward to follow.  

For example the ASCII art makes it seem there is delay in the system whereas
an implementation could actually eliminate much of that delay.  As a
specific example, the ASCII art shows message 10 (containing Bob's SDP
answer) is received by Alice's SIP proxy and then Alice's SIP proxy spends
time communicating with Alice's Policy device (messages 11 and 12) before
sending the message along to the Alice endpoint itself (message 13).
However, as long as Alice's Policy device has received that communication
sometime prior to Alice's Firewall doing its authorization check in message
15, the authorization will still work.  A flow like this could be
envisioned:

  ...
     |             |(10) answer, token=B:b     |             |
     |             |<----------------------------------------|
     |(11) answer, token=B:b     |             |             |
     |<------------|             |             |             |
     |             |(12) new session, token=B:b|             |
     |             |............>|             |             |
     |             |(13) OK      |             |             |
     |             |<............|             |             |
     |(14) STUN Request, token=B:b:A:a         |             |
     |========================================>X             |
     |             |             |(15) token B:b:A:a ok?     |
     |             |             |<............|             |
     |             |             |(16) Yes     |             |

The risk is of this flow is a race condition -- message 14 and 15 could
occur before message 12 occurs.  This race condition could be resolved by
having the policy server only send a "no" in message 16 after waiting a
"reasonable length of time" (a second, perhaps) for the possible arrival of
message 12.  However, this would require storing more state in the policy
server if there is a flood of message 14's or spoofed message 14's which
will never be authorized by any SIP proxy because there really isn't an
signaled SIP call associated with that 5-tuple or with the token values.

Hope that helps.

-d

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 22 Mar 2006 23:21:57 -0500

I have been studying this draft and have I think an important comment. The
firewalls shown in the diagrams and described in the text should be replaced
or further described as to their function.

Specifically, most firewalls typically perform a NAT, and indeed a NAT at
the edge of a carrier network would break the "natural routing" benefits of
this proposal.

I would suggest in text and diagrams to clarify the firewall as either a
filter or a nat.

I also would suggest discussing a few additional potential downsides to this
approach. One would be that if "natural routing"  is used, there will need
to be a firewall-filter on each and every path that could support this
route. Thus the downside is that for a large network with many physical
peering interconnections, there would need to be a firewall-filter on every
interface.

I also would like to suggest an improvement to this architecture. That would
be to optionally have the firewalls perform a NAT. In this mode, the STUN
message would be NAT'ed on its way to the destination AFTER the policy
look-up. This may allow the policy server to instantiate a translation
before the STUN message is returned to its egress processing at the
firewall-nat device. Advantages here would include being able to interwork
with RFC1918 addressed devices in the network your interconnecting with.
Additional advantages are that this would permit reduction of the number of
physical interfaces requiring a firewall-nat since you could now use a /32
route to represent the entire destination network restricting that route to
a handful of interconnect points. This would waste a real IP address, but it
may well be worth it given the savings on the alternative of equipping every
interface between the two networks.

One minor suggestion would be to replace the references of "natural routing"
with something that is more accurate. The reason for this is that I do not
know what you mean by the opposite - unnatural routing. And then there is
always the possibility of supernatural routing. Not being a routing expert I
don't want to suggest a term here and I know what you mean is BGP4 or OSPF
based packet forwarding mechanism. But I would suggest it could be more
accurately defined.

Finally - at the working group you presented a diagram showing BOB trying to
talk to ALICE. I know that the values of the IETF are to not build any
walled gardens -- but I worry that if BOB wanted to send a STUN packet or
even a RTP packet to alice that wasn't part of the peering arrangement, then
the packet would be dropped. This would in effect cause the path to not be
used for best efforts uses. While this is good and desired for peering
interconnect, if Natural Routing is used, the Natural Routers would have to
be Super Natural Routers to figure out how to route around those stun and
RTP messages being used by Google Talk or other service providers that Bob
or Alice might want to use.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Mar 2006 16:45:05 -0800

> I have been studying this draft and have I think an important
> comment.  The firewalls shown in the diagrams and described in the
> text should be replaced or further described as to their function.
>
> Specifically, most firewalls typically perform a NAT, and indeed a
> NAT at the edge of a carrier network would break the "natural
> routing" benefits of this proposal.

I agree.  However, the reason ITSPs like to hide the IP address of
remote endpoints is to hide the business relationship to the 
next-hop ITSP, and to force the RTP traffic to stay on their own
network so they can charge for delivery of a service and to monitor
that RTP traffic (such as for MOS monitoring).

Not all businesses need or want to do that.

> I would suggest in text and diagrams to clarify the firewall as
> either a filter or a nat.
>
> I also would suggest discussing a few additional potential downsides
> to this approach.  One would be that if "natural routing"  is used,
> there will need to be a firewall-filter on each and every path that
> could support this route.  Thus the downside is that for a large
> network with many physical peering interconnections, there would
> need to be a firewall-filter on every interface.

Ok.

> I also would like to suggest an improvement to this architecture.
> That would be to optionally have the firewalls perform a NAT. In
> this mode, the STUN message would be NAT'ed on its way to the
> destination AFTER the policy look-up.  This may allow the policy
> server to instantiate a translation before the STUN message is
> returned to its egress processing at the firewall-nat device.
> Advantages here would include being able to interwork with RFC1918
> addressed devices in the network your interconnecting with.
> Additional advantages are that this would permit reduction of the
> number of physical interfaces requiring a firewall-nat since you
> could now use a /32 route to represent the entire destination
> network restricting that route to a handful of interconnect points.
> This would waste a real IP address, but it may well be worth it
> given the savings on the alternative of equipping every interface
> between the two networks.

An implementor building a box that does both NAT functions and
implements -wing-session-auth would very likely build such a box
like that, yes.

> One minor suggestion would be to replace the references of "natural
> routing" with something that is more accurate.  The reason for this
> is that I do not know what you mean by the opposite - unnatural
> routing. 

Routing from Alice directly to Bob, without sending IP packets to
a media relay device or a media proxy device.  Obviously if Alice
or Bob have a NAT in front of them, you'll be sending the packets
to the NAT, but that isn't avoidable.

> And then there is always the possibility of supernatural
> routing.  Not being a routing expert I don't want to suggest a term
> here and I know what you mean is BGP4 or OSPF based packet
> forwarding mechanism.  But I would suggest it could be more
> accurately defined.

Ok.

> Finally - at the working group you presented a diagram showing BOB
> trying to talk to ALICE. I know that the values of the IETF are to
> not build any walled gardens -- but I worry that if BOB wanted to
> send a STUN packet or even a RTP packet to alice that wasn't part of
> the peering arrangement, then the packet would be dropped. 

> This
> would in effect cause the path to not be used for best efforts uses.
> While this is good and desired for peering interconnect, if Natural
> Routing is used, the Natural Routers would have to be Super Natural
> Routers to figure out how to route around those stun and RTP
> messages being used by Google Talk or other service providers that
> Bob or Alice might want to use.

Unfortunately my SPEERMINT presentation poorly represented the value
of -wing-session-auth to the SPEERMINT working group.  

The draft (and my presentation) describes how you might use media
session authorization to completely deny UDP packets to or from an
endpoint.  That is the common firewall policy at many enterprises.  Of
course, for an ISP offering Internet connectivity, dropping UDP
packets to or from an endpoint is not their standard policy.  Instead,
their standard policy is to permit such packets.  Such an ISP may
additionally wish to offer better QoS on the access link for UDP flows
that are associated with flows that are signaled -- such as flows
signaled  via the mechanism described in -wing-session-policy.

Thank you for reviewing my I-D and seeing the applicability of this 
technology to peering.

-d