Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> Sent: Tuesday, September 18, 2012 6:20 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]; Dan Wing (dwing); Prashanth Patil (praspati); Pal
> Martinsen (palmarti)
> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-
> mobility-01.txt
> 
> Hey Tiru,
> 
> On 18.09.12, 14:07, Tirumaleswar Reddy (tireddy) wrote:
> >> > The only reason I can think why ICE Mobility would fail and ICE
> >> > restart succeed is because of Simultaneous Mobility
> >>
> >> Well ... I might be missing something but it seems to me that the only
> >> time it would succeed would be when there's a direct reachability
> >> between the mobile node's new address and their correspondent.
> >>
> >> This would be the case when the mobile node has moved into the same
> >> NATed network as the correspondent, or when the correspondent has a
> >> public address with no one to perform endpoint dependent filtering in
> >> front of them.
> >>
> >> In all other situations (which would likely represent the majority of
> >> the cases) ICE mobility would fail and one would need to perform an ICE
> >> restart.
> >>
> >> Emil
> >
> > Hi Emil,
> >
> > Thanks for the review.
> >
> > I have assumed that the other Mobile Device (Correspondent Node in this
> > case) would include MOBILITY-SUPPORT only in the following cases :
> > IPv6 Global Address,
> 
> And I insist, even with IPv6 there should be no that performs endpoint
> dependent filtering in front of the CN. Many corporate firewalls would
> not allow incoming traffic unless it has been initiated from the inside.
> Just as they would for IPv4.
> 
> > Correspondent Node is behind Endpoint-Independent
> > Mapping/Filtering NAT as recommended in RFC 4787.
> 
> While 4787 is quite adamant about avoiding endpoint dependent mapping
> this is not the case for endpoint dependent filtering:
> 
>   RTF 4787, REQ-8: ... If a more stringent filtering behavior is most
>   important, it is RECOMMENDED that a NAT have an "Address-Dependent
>   Filtering" behavior.
> 
> That text aside, while one could hope that (at least in certain parts of
> the world) a decent number of CNs would be behind a NAT with endpoint
> independent mapping, it is very rare to see commercial deployments with
> endpoint independent filtering.
> 
> > But to make it work in other scenarios where Correspondent Node(CN) is
> > behind Address-Dependent Filtering/Mapping, CN can detect the NAT
> > behavior using simple tests suggested in RFC 5780 and so not include
> > MOBILITY-SUPPORT attribute.
> 
> That kind of diagnostics are extremely difficult to apply in practice
> (which is one of the reasons for ICE to exist) and even if they weren't,
> disabling ICE mobility for NATs with endpoint dependent filtering would
> leave you with very few cases where one would be able to use it.

Hi Emil,

Thanks for the detailed explanation. We will add details that ICE agent will try ICE Mobility and ICE restart in parallel. So that in case of Endpoint dependent filtering/Firewall scenarios even if ICE Mobility fails, ICE restart would succeed. 

[1]Endpoint independent mapping/filtering -> No issues with ICE Mobility.
[2]Endpoint dependent mapping -> ICE peers will have to use UDP relays. Mobile Devices will end up using the technique in section 4 of the draft (Mobility with TURN)

--Tiru.

> 
> > [Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE
> > compliant NAT then ICE connectivity checks using host/server-reflexive
> > candidates will fail and end up using UDP relay]
> 
> Well again, NATs with endpoint dependent filtering are totally fine with
> 4787 and they do work with server-reflexive addresses.
> 
> Cheers,
> Emil
> 
> --
> https://jitsi.org