[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    RE: [Ipsec] Questions regarding NAT traversal in IKEv2
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2007-09-11 12:37:12
Message-ID: 18150.35832.869574.172004 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]

Christian.Kaas-Petersen@tietoenator.com writes:
> In the setup as presented, the initiator's SPD will have an entry
> covering the address pair (A, Y); similarly the responder's SPD will
> have an entry covering the address pair (A, Y), else it could not
> return the TSi = A, TSr = Y.  A packet sent from initiator will be
> 
>     IP header src = A, dst = Y
>     ESP
>     TCP
>     data
> 
> but after having passed the NAT box, it will be
> 
>     IP header src = X, dst = Y
>     ESP
>     TCP
>     data
> 
> (The IKEv2 exchange has detected NAT boxes, so I guess also a
> UDP header ought to be inserted.)
> 
> Question: The responder is the only node knowing about the relation
> of A and X.  Is there anything hindering the responder to fix the
> TCP checksum both for received and sent packets?

When we were doing the NAT-T for IKEv1, my idea was that responder
would be fixing the checksum all the time (for sent and received
packets), but other people didn't like that idea, thus they required
recipient of the packet to fix the packet (which do make sense in case
you have responders also behind the NATs). So the RFC3948 defines that
recipient of the packet needs to fix it. As IKEv2 uses the same
RFC3948 it uses the same method.

So in the end you end up requiring checksum recalculation in the
recipient end in IKEv2 always. 
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]